はじめに
本サイトの記録を残してみようと思います。ほとんど気まぐれと自己満足によるものです。
2022/12/01
2022/5/13に気付いて対処した現象－1/8のおはっちに1/9になってからおはっちリプした人が意図せず「1/8の1番おはっち」として認定されて平均値がおかしくなった件－が再発した。今回は11/25のおはっちに対して11/26になってからリプした人を、ひなっちが1番おはっちと認定している。
このため62627秒が計上されて、平均値が110秒ちょいに異常増加した。
以下が修正前の状況
11/25のおはっちに対して、11/26になってからリプした人を、ひなっちが1番おはっちと認定している状況
11/25のおはっちに対する1番おはっちリプは、以下のようにその日のうちにひなっちから既に認定されている。つまり、11/25の1番おはっちが二重で発生して、1回目が意図せず上書きされた形。
5/13に記載した対処と同様、以下を対処。
- 11/25の1番おはっちの再処理
- 不要に計上された62627秒を減算した形で平均値を再計算
今回の件を時系列で並べると以下の通り。(時刻はすべてUTC)
- 11/25 06:28:00 ひなっち、11/25のおはっちツイート
- 11/25 06:28:05 11/25のおはっちに対して「おはっちリプ」
- 11/25 06:30:25 ひなっち、2.に対して「1番おはっち」認定リプ
- 11/25 23:51:47 11/25のおはっちに対して「おはっちリプ」（←※今回これが意図せず「11/25の1番おはっち」と認定されてしまった）
- 11/26 00:25:21 ひなっち、11/26のおはっちツイート
- 11/26 01:33:11 ひなっち、4.に対して「1番おはっち」認定リプ
11/25分の1番おはっちは3.で一度認定済だが、それが6.で意図せず上書きされてしまっている。
時系列から見ても6.は「11/26分の1番おはっち」を認定したかったと思われるが、認定先のリプが11/25のおはっちツイートに対するリプだったために、6.の処理が「11/25の1番おはっち認定処理」とみなされてしまった。
時系列で並べると一目瞭然だが、4.はそもそも11/26のおはっちよりも「前」に発生しているデータなので、11/26分として見ると、「まだその日のおはっちツイートがされてないときに行われたリプ」になるため、11/26分として認定され得ない（されてはいけない）はずなのだ。
まあ、なんか混乱しちゃったんだろう。11/26 SAIだったからな。（関係あるかわからんけどｗ）
なお、1/9のときと同様だが、この結果、11/26分の1番おはっちが欠落している形になる。
11/26のおはっちツイートの中に（認定されていないだけで）「"真の"11/26の1番おはっち」がどこかにいるんだろうが、11/26に関しては、ひなっちのおはっち認定が実質存在しないため、不明である。
上で言う4.を（リプ先が11/25になってはいるが）ひなっちの認定通り「11/26の1番おはっち」としてリカバリしてもいいかと一瞬考えたが、11/26のおはっちより前のリプなので、それもおかしいと結論付けた（そのまま馬鹿正直にリカバった場合、「1番おはっちまでの経過時間」が負数になることになり、通常の運用として明らかにおかしい）
というわけでこの状態のままリカバリ完了とさせていただく。
2022/5/24
GAE＋Typescriptによるリメイクを（一旦）完了し、リリース。この日の更新分から新サイトにて運用開始。
ちょっとまだいくつか残課題がある関係でちょいちょい手入れはするだろうが、基本形は完成したので、徐々に運用フェーズに移行していく。
色々学びがあったので、そのうちブログに書き留める予定。
2022/5/13
実はちょっと前から気付いていたんだが、「1番おはっちまでの平均秒数」がなぜか240秒とか異常な数字になっていて、なんだこりゃ？と思っていた。この頃並行してサイトのTypescript＋GAE化を進めていて、そっちのほうを優先していたので、この対応を後回しにしていたのだが、ちょっと一息ついたので、調べてみようかなと思って調べて対応した。
調べてみてわかったが、これは別に（一応）バグではなくて、2022/1/8のおはっちに対して翌日1/9になってからリプした人がいて、この人を「1番おはっち」とひなっちが「認定」してしまったため、システム的には「1/8の1番おはっちが1/9になってから＝つまり約24時間後（実際には84641秒後）に行われた」と判定して、ここで数字が狂った模様。
修正前の状況は以下
当日の記録を見る限り、2022/1/8の真の1番おはっちはこっちである。実際、当時の処理ログにも、このリプが1番おはっちとして処理された記録が流れている。
一方、2022/1/9に再度1番おはっち認定がされていて、それがこれ。
このリプは2022/1/8のおはっちに対してリプされていて、かつこれをひなっちが（恐らく）「1/9の」1番おはっちと勘違いして認定リプしたため、上の「真の1/8の1番おはっち」が上書きされてしまった。この際、1/8のおはっちした時間から、この1/9の偽1番おはっちまでの経過時間84641秒が、システム的には「実際に1番おはっちされるまでそんだけかかった」と判定されて、平均値の計算に使用された。その結果、平均値の数値がおかしくなった、という経緯。
とりあえず、2022/1/8の1番おはっちとして一度認定されたリプが意図せず上書き更新されてしまっているのは事実なので、もう一度2022/1/8の1番おはっちを再処理して書き直した。
かつ、余計に計上されている84641秒を、本来の1番おはっちの経過時間（このときは6秒）に修正し、これに基づき平均値を再計算した。
一旦、これで修正対応は完了。
なお、これに関しては実際あと一つ問題が残っている。
1/9の1番おはっちが存在していない（欠落している）のである。
1/9の1番おはっち認定（と思われる対応）が、1/8のおはっちに付いてるリプに対して行われ、1/9のおはっちに付いてるリプに対しては行われた事実がないためだ（2番～5番は1/9のリプに対して正しく行われている）
ただ、実際のところ、これの判断は難しい。
というのも、この1/9になってから行われたリプが、「1/8のおはっちに対して（本当に気付かずに）翌日なってから遅れてリプした（そしてたまたまそれが1/9のおはっちと時間が重なった）」のか、「1/9のおはっちに対して1番おはっちを狙っておはっちリプするつもりだったが間違えて1/8のおはっちに対してリプしてしまった」のか、こちらからでは判断がつかないからだ。
仮に前者なら1/9の1番おはっちではないし、後者なら1/9の1番おはっちとして扱ってもよいはずだ。
一方でひなっちがこれを「間違って」認定していたのだとしたら、上述したリプした人の動機に依らず、1/9の真の「1番おはっち」は、実際に1/9のおはっちに付いてる別のリプとして存在していることになり、やはり「1/9の1番おはっち」と見做してはいけないことになる。
システムのコンセプト上、ひなっちの認定によってデータが作られている仕様であり、少なくともひなっちがこのリプを「1番」と認定しているという事実を考えれば、このリプは（1/8のおはっちに付いてはいるが）「1/9の1番おはっち」と見做しても（つまり後者の判断でも）良いのかもしれない。
とはいえ、状況から推察するに、「リプした人の動機」と「ひなっちの行動の真意」が複雑に絡み合っており、「少なからず私の予想をもとにしないと結果が定まらない」という状況を考えると、やはり1/9の1番おはっちはこのまま欠落状態にしておいたほうが良いのだろうと思うに至った。
よって今のところこのまま手出ししていない状態である（決してリカバリ作業が面倒だったわけではない！ｗ）
2021/9/25
IFTTTのTwitter連携で不具合発生。具体的に言うと、IFTTTからTwitterトリガーでWebhookに連携している項目のうち、「LinkToTweet」が空っぽになっている。
Twitterで同様の事象を検索してみた限りでは、同じ現象に悩まされているユーザーがいたようだった。
この現象は9/27から復旧した。(9/25、9/26分はcurlでパラメータに指定のツイートのURLを指定し、直接Cloud Functionsを呼び出して処理した)
細かい話だが、復旧後に「LinkToTweet」の値がhttp始まりではなくhttps始まりに変わっていた。
2021/9/14
この日はいくつか問題があって、、、- 前日にとある理由でCDN側の設定を変更していたのだが、その影響で一部の処理が正常動作しなくなってしまった。
（こっちの処理にまで影響が出るのを完全に失念していた）
このせいで一部のデータが不完全なまま処理された状態になってしまった。 - 上記1.の修正をかけてリランをかけたが、また落ちる。
調べてみると、「Twitterでは同一文言で連続投稿できない」という仕様があり、これにひっかかっていた。
リラン時点で最後のTwitterの投稿が当日の「ひなっちのおはっちが更新されました」だったので、同一文言で再度APIでPOSTしようとしていたので、これに引っかかってエラーになっていた。
毎日同じ文言で更新の投稿をするのも良くないなと今さらになって思うに至り、更新処理通知時の文言に日付と日時をいれるように変更した
2021/9/1
処理後の画面を見てみると、内部的には更新処理が終わっているように見えるのに、データが１つも見えないという、奇妙な状況になっていた。データを見てみると、通常発生し得ない形でデータが作られていた。
twitterで検索してみた結果、IFTTTの障害と発覚した。
当該時間帯において、IFTTTのTwitter Integrationで障害が発生していたと、公式のほうでも言及があった。
というわけで各種ツイートを参照しながらConsole上から直接データベースにデータ投入してリカバリ。
2021/7/5
3番おはっち認定が2回発生。データの発生順序や、文言などを考えても、1回目が本当の3番おはっち認定で、2回目は恐らく5番おはっち認定の間違え（誤って3番と記述してリプしてしまったと思われる）。
これにより、2回目（5番おはっち）が1回目（本当の3番おはっち）を上書きしてしまった。
ツイート処理機能に、1回目（本当の3番おはっち）のツイートを指定・手動実行して、本当の3番おはっちを復旧。
2回目（5番おはっち）は処理ログをもとにConsole上から直接データベースにデータ投入してリカバリした。
2021/7/4
Search機能をオープン。本当はユーザーIDをキーに検索をかけるようにしたかったのだが、普通に考えると一般的にTwitter使ってる人は自分（や他人）のユーザーIDを知らないはずで、検索項目にしたところで基本的に打てるわけがない、ということを考え、しぶしぶScreenNameでの検索にした。
ご存知の通り、ScreenNameは変更できるので、厳密な意味でユーザーの履歴検索にならないという点が個人的に満足できていない。
ScreenNameを入力されたら、Twitter API投げてユーザーID取得してからDBに検索かけるというのも、できなくはないが、この場合、Twitter APIは私のアカウントで実行させることになり、これを画面機能としてオープンにしてしまうと、不特定多数の人から四六時中実行できてしまうわけで、実効レートに払拭する可能性が出てくるため、採用できない（まあそんなにアクセス数もないんだけどね）。
というわけで現時点ではScreenNameを採用せざるを得なかった。
ここはそのうち見直したいところではある。
2021/7/1
おはっち認定されたユーザーが鍵垢のため、Twitter APIで当該ユーザーの情報取得不可能（APIの実行結果が空オブジェクトになる）これによりツイートの処理機能がコケた。
Twitter APIの実行ユーザーは私のアカウントに紐づくため、私と相互フォローの関係にないと、TwitterクライアントやWeb画面で当該ユーザーのツイート等が見れないのと同様に、APIでもデータが取得できないのだろう。
そういう事情のため、これはもうどうしようもない。私からはどう頑張ってもこの方のツイート情報を取得できないためだ。リカバリ不可能。いつか相互フォローになったら教えてください。
2021/6/26
後日気づいたのだが、4番と5番おはっちが存在しない。
これは単純に4番と5番のおはっち認定リプを実施していないだけ。
1番～3番は実施してたので、忘れただけだと思われる。
こういう日もある。
ちなみに「ひるっち！」というリプに対して「リプありがとうございます！」と返してるので、これが4番か5番のいずれかである可能性はある。面倒くさいから調べてないが。
2021/6/15
ひなっちが「おはっち」以外の文言でおはっち認定をしている。(具体的には"わすれっち"という文言で認定している)
このため当該ユーザーのリプがn番おはっち認定されなかった。
ツイートの処理機能は処理対象とする文言をコード外の設定値のような場所に持たせている。
このため、この設定値を"おはっち"から"っち"のように変更して、当該処理機能を処理実行すれば、コード変更を伴わずリカバリ可能。
実際そうやってリカバリした。リカバリ後、上記設定値をもとの値に戻す。
こういう作りにしておいてよかったと思った出来事。
2021/5/22
ひなっちのおはっち認定が、オリジナルおはっちへのリプではなく、単独のツイートで行われる。
これによりリプライ先のユーザーの特定ができず、想定通りに処理が出来なかった。
単独ツイートのリプライ先ユーザーを確認→オリジナルおはっちのツイートに対するリプから当該ユーザーを探し、当該ユーザーのリプライを確認→当該リプライのデータをTwitter APIで取得→システム機能で処理された体でデータを手動で加工の上、Consoleから直接データベースにデータを登録
という面倒なことをやってリカバリした。
2021/4/23
本サイト開設。正確に言うとサイト自体は4月上旬には開設していたけども、Twitterで開設を告知したのはこの日が初。
翌日ひなっちにリツイートしてもらい、アクセス数が100倍くらい増える。