予約ページに、二つの入口を作っていた。ひとつは通常の予約、もうひとつはイベントの予約。同じページを使い回し、リンクに「これはイベント用」という合図を一つ付けて、開いたときに切り替える。そういう仕組みだった。
ところが、LINEからそのリンクを開くと、いつも通常の予約になった。イベント用のはずが、合図が効いていない。手元のブラウザで直接開くと、ちゃんとイベントになる。LINEから開いたときだけ、切り替わらなかった。
リンクには、確かに書いてあった
リンクそのものを見ると、合図はちゃんと付いていた。
「これはイベント用」という印を、URLの末尾に載せている。手で開けば、その印はページまで届く。だからイベントとして表示される。理屈は合っていた。合っていたのに、LINE経由だと届かない。
経路の途中で、はぎ取られていた
犯人は、LINEの中でページを開くときの、経路だった。
LINEの中でこの手のページを開くと、いったん専用の仕組みを通って、目的のページへ渡される。その受け渡しの途中で、URLに載せていた合図が、はぎ取られていた。開いた先まで来たときには、印はもう消えていた。
送った本人は、ちゃんと送ったつもりでいる。けれど、届いた先では無くなっている。経路の途中で落ちていたのだ。
届いた瞬間に、手元へ写す
直し方は、届いた瞬間をつかまえることだった。
ページが開いた、いちばん最初。まだ合図が残っているかもしれない、その一瞬のうちに、印を自分の手元へ写し取っておく。ブラウザの中に、一時的にものを置いておける場所がある。そこへ退避させる。
以降は、URLではなく、写し取ったほうを見る。たとえ経路の途中で元の印が消えても、手元の控えは残っている。これで、LINEから開いても、イベントとして正しく表示されるようになった。
経路は、信用しない
この件で、一つ考えが変わった。
外から渡された情報は、目的地まで無事に届くとは限らない。途中に何段の受け渡しがあるか、そのどこで何が起きるか、こちらからは見えない。見えないものを、あてにしてはいけない。
だから、大事な情報が届いたら、まず自分の手元へ写す。経路を信じるのではなく、手元の控えを信じる。渡ってくる道の長さも、その途中の作法も、こちらには変えられない。変えられるのは、受け取った瞬間の自分の動きだけだ。
「効かない」ときは、まず届いているかを見る
合図が効かないとき、つい合図を使う側のコードを疑ってしまう。
けれど今回のように、そもそも合図が届いていない、ということがある。使う側は正しくても、渡す途中で消えていれば、何をしても効かない。
だから「効かない」と感じたら、まず確かめる。その情報は、本当にここまで届いているのか。処理を直す前に、届いているかどうかを見る。この順番を守るだけで、見当違いの場所を掘り返す時間が、ずいぶん減った。