COCOAの最新版「1.4.0」でアプリが強制終了との報告。iPhoneおよびAndroid版いずれも 86
ストーリー by nagazou
やっちゃったか 部門より
やっちゃったか 部門より
nagazou 曰く、
厚生労働省は25日、COVID-19接触確認アプリ「COCOA」の最新版「1.4.0」の提供をApp StoreとGoogle Playで開始した。しかしこのアップグレードにより、iPhoneおよびAndroidともにCOCOAが強制終了する報告が相次いでいるようだ。ITmediaが25日午後7時段階で編集部内で試したところ、iOS 15.1.1を導入したiPhoneでは起動できなかったとしている。厚生労働省も状況を把握はしているようで、COCOAの配布ページ上で「原因を調査の上、別途案内させていただきます」と告知している（COCOA公式、ITmedia）。
事後対応だけは満点 (スコア:3, 興味深い)
COCOA v1.4.0 が起動しない · Issue #517 · cocoa-mhlw/cocoa [github.com]
に書かれている通りで、まず半年以上前に
とかいうクソコードが入っていたが原因その1。JavaやJavaScriptと勘違いしたのか現在時刻を取得するつもりでnew DateTimeを呼んでいるように見えるけど、C#では時刻の最小値が初期値に設定されるので、古いバージョンから使い続けている利用者は利用規約の最終同意日時が「1/1/0001 12:00:00 AM」になっていた。そもそも引数の中でnew DateTimeする時点で有り得ないし、ド素人がプログラムしていたと思われる。
で、そうとも知らないkeijiがスラドでも取り上げられた日付フォーマットの問題（接触確認アプリCOCOA、地域ごとの日付フォーマットの違いで利用日数が狂う新たな不具合 [opensource.srad.jp]）を修正するためにv1.4.0でJST(UTC+9)からUTCに直すマイグレ処理を追加したのが原因その2で、「1/1/0001 12:00:00 AM」からマイナス9時間しようとしてエラーを吐いて無事死亡。
利用規約の最終同意日時がおかしいことに誰も気付かなかったのは、利用規約の更新があっても再確認を行わない [github.com]という仕様をなぜか放置していたのと、当時の担当者がデータ仕様をドキュメント化していなかったせいで、一カ月前にkeijiがデータ仕様をドキュメント化した際 [github.com]にも見落としてしまった。
2つのマイグレ処理が絡んだ問題なので表面的なテストやストア審査では見抜けなかったのは同情の余地があるけど、コーディング能力や開発速度が低すぎるし、大金積んだ国策アプリの品質じゃない。
Re: (スコア:0)
大金積んだ国策アプリの品質じゃない。
大筋合っていますが結びだけがズレています
いくらかけようとも末端の技術者に行くお金は毛ほども変わらない
そもそもの目的が丁度いいネタが有ったから
えらいひとで美味しくチュウチュウしちゃおうぜ
なのだから品質自体を期待しちゃいけない
# 国策とはそういうものなのよねぇ
Re: (スコア:0)
COCOAは有志開発アプリじゃありませんでしたっけ？（すっとぼけ）
Re: (スコア:0)
マジレスするとCovid-19Radarは有志開発（という建前）だけど、今回問題のコードは完全に厚労省/デジ庁管轄下のCOCOAになってから追加されたコードだからねぇ
Re: (スコア:0)
githubでオープンになっていて、誰でもチェックでき、誰でも指摘できるコードのハズなのに、
誰も指摘しない時点で日本国のプログラマー達の能力も知れているかと…。
Re: (スコア:0)
まあオープンだから事後的な原因の特定は早かったよね。
事前に張り付いてコードチェックするのはちょっと無理ゲ。
Re: (スコア:0)
Xamarinの開発者なんてレア過ぎて米国でも無理だよ。
そうやって日本ダメって結論から変な思考する変な癖はやめた方が良い
Re: (スコア:0)
Xamarin (C#)で開発してるならWIN版、もそのまま作れないの？ 宗教上の理由でガラケー男
Re: (スコア:0)
COCOAの持つ機能のほとんどはGoogleとAppleがスマートフォン向けに提供しているEN APIに依存しているので、それがないWindowsではほとんどの機能が動作しない。
Re:事後対応だけは満点 (スコア:1)
えーん😭
Re:事後対応だけは満点 (スコア:1)
蛮勇だったってことか
Re: (スコア:0)
これもXamarinを採用した為の弊害でしょうね
クロスプラットフォームといいつつ端末間の差異も吸収出来ず、さらに.NET依存の問題も絡んでカオス状態。
Xamarin開発に固執した為に開発者を除外する環境が生まれ開発の質が上がらない。
MSの思惑としてはXamarin開発の実績を示したい筈なんだろうけど、どんどん悪評が高まっているだけ。
こんなんじゃ「Xamarin？COCOAでバグ出しまくってる奴？」と企業採用すらされないよ。
Android Studio / Xcodeで分けて開発した方が結果的に安価で質の高いアプリを提供できる筈
Re:事後対応だけは満点 (スコア:1)
HAHAHA! このレベルの開発体制なら、Android Studio / Xcodeに分けた開発したらバグが2倍になるだけに決まってるじゃないですか（涙
Re: (スコア:0)
JavaやJavaScriptと勘違いしたのか現在時刻を取得するつもりでnew DateTimeを呼んでいるように見えるけど
旧バージョンの利用規約同意しか取れてないのに、
現バージョンの利用規約同意済みとみなされかねない現在時刻をセットしちゃだめでしょ・・・
COCOAって気休め以外に (スコア:0)
なにか効能があったのだろうか?
類似のアプリもそうだけど、検証してみてほしい
# アマビエを表示と大差ないと思う
Re:COCOAって気休め以外に (スコア:1)
チャットできて便利ですよ。対面で話さないことで、感染防止に役立ちます。
毎年3月に使用期限が延びるのを見て一安心、というのが個人的な風物詩ですね。
Re: (スコア:0)
検証ってなかなか難しそうだねぇ
どうやってやるのがいいんだろ
Re: (スコア:0)
>なにか効能があったのだろうか?
中抜は好調でしたね
COCOA開発受注企業が事業費94％を3社に再委託、さらに2社に…不具合の原因企業「分からない」
https://www.tokyo-np.co.jp/article/87051 [tokyo-np.co.jp]
Re: (スコア:0)
碌に仕事をしなかって件については、「会計検査院法第34条の規定による処置要求及び同法第36条の規定による処置要求 [jbaudit.go.jp]」で詳細が報告されています。
Re: (スコア:0)
最初から知識があれば分かってたことを強行しておいて今更検証とか金の無駄すぎでしょ
Re: (スコア:0)
なにか効能があったのだろうか?
関係するえらいひとたちが無事に美味しい思いができた
それ以外になにか必要なことがある？
# 碌でも無い仕組みを買えたければ選挙に行こう
Re: (スコア:0)
アマエビを表示
なにそれ、美味しそう。
yoshi! (スコア:0)
デバッガ「エミュレーション環境でチェックチェック～いけるねうん。OSバージョン別動作とかはまぁ無視して大丈夫でしょ。ﾖｼｯ」
配信担当「いけたみたいだね、俺は配信するだけだし。配信GO～～～～ ヨシッ！」
開発担当（ガラっ）「あのー、言い忘れてましたけど今回のバージョンから新しい機能いろいろ付けたんで動作チェックOS別に細かくお願いしますね～」
一同「。。。。。『原因は調査中です、まる』っと。よしっ！！」
Re: (スコア:0)
実機試験しなかったせいでNGって前にもやって見事に大失敗しなかったっけ…
Re: (スコア:0)
同じようなことamazonのアプリストアもやらかしてるんですよね。
実機(google端末)のandrorid12環境だとまともに動かないのに、サポートに問い合わせるとandroid12で動作確認済みですと言う返答が帰ってくる状態でした。
(今は公式に不具合対応中になってます)
OSだけチェックすれば良いと思ってるの？ (スコア:0)
本件のissue [github.com]より、
特定バージョン(v1.2.0)より前からのアップデートでデータが壊れ、
今回のバージョンでアプリが落ちる。
実機でやってないからとか、OS別にやったからヨシなんてものではなく、
真っ新な状態や旧バージョンからアップデート後の状態別にテストが必要と
指摘できなければ、同じ穴の狢だろ。
Re:OSだけチェックすれば良いと思ってるの？ (スコア:1)
> 特定バージョン(v1.2.0)より前からのアップデートでデータが壊れ、
> 今回のバージョンでアプリが落ちる。
いや、そうとも限らないです。
v1.2.0を経由していても駄目な場合があるという報告があります。（事実であれば）
あと、データが壊れる、というのもちょっと違うかと。
利用規約を読んだ日時を記録するデータがあって、
条件によっては、これが最小値（Ticks = 0 : グレゴリオ暦0001年1月1日0時0分0秒）のままになるみたい。
（利用規約を読んだフラグだけ立って、日時が記録されていない状態）
最大のミスは、DateTime型への加減算で例外が発生しうることを認識していなかったことじゃないかと。
JSTとUTCの変換時に9時間分の減算を行っていて、
これが最小値より前の日時になると例外が発生してアプリが止まります。
指摘に「標準のタイムゾーン変換関数を使わないから」というものもありますけど、実はこれも間違い。
標準の変換関数を使おうが、最小値より前になれば例外が発生します。
最新OS (スコア:0)
iOS 15.1.1って最新バージョンだよな？
最新バージョンの実機テストすらやってないのか
Re: (スコア:0)
最新バージョンだからこそ、やってなかった
ということもよくある。
だって最新のテスト環境がなかったんだもん。
15.1.1って、マイナーバージョンアップでしょ。大丈夫、大丈夫。
Re: (スコア:0)
むしろ今更なアプリを毎バージョンテストしてほしいか？
予算浪費して
Android版は動いた (スコア:0)
昨日の夜にAndroid 11環境で1.4.0にバージョンアップしたら普通に動いてるんだけど、どういう条件でダメなんだろ？
Re:Android版は動いた (スコア:2)
Pixel4aのandroid12環境だと昨日の夜にアップデートしたら異常終了するようになりました。
もしやと思って、データを初期化したら動作するようになったので、データの読み込みがイクナイんでしょうね。
ios版は直った模様 (スコア:0)
11:49 時点の記事 [impress.co.jp]
Android がまだなのは、確認する端末やバージョンが多いせいなのかな
これがLINEやTwitterなら大混乱だが・・・ (スコア:0)
まったく役に立ってないから起動しなくてもまったく影響ないという
会社の出勤簿システムが止まった時ですら紙にメモるかメールで代替えしたのだが
11時にiOS版は治ったらしいので追記してほしい (スコア:0)
https://twitter.com/digital_jpn/status/1464051889348116482 [twitter.com]
iOS 15.1.1 (スコア:0)
iOS 15.1.1では、iPhone12およびiPhone13のモデルで通話中に音声が途切れる現象が改善されます。
どこにCOCOAが影響を受ける要素があったんだ？
原因を見るとなるほどなぁ…という感想 (スコア:0)
githubに不具合原因が書いてあるので詳細割愛しますが、
WindowsとLinuxで取得するタイムゾーンの名称が異なることが原因で
エラーになっていたようですね。
COCOAはXamarin(.NET)を使用しているのは既知の通りですが、
Microsoftのドキュメントに書かれているコードを
開発者がそのまま信用して書いてしまったようですね。
当方も.NET Core(現.NET6)でクロスプラットフォーム開発していますが、
確かに類似のケースはあり、悩まされることもあります。
MicrosoftのドキュメントはどうしてもWindowsベースで書かれているので、
落とし穴が多く感じますね。
もっとも、ちゃんと動作確認しろよ！って言われたらぐうの音も出ないと思いますが。
一方で、Microsoftもクロスプラットフォーム開発を売りにするならドキュメントをちゃんと書いて欲しいですね。
Re:原因を見るとなるほどなぁ…という感想 (スコア:3, 参考になる)
githubのコメントを読みましたが、違うみたいですよ。
1. Xamarinがそういうタイムゾーン周りの問題を抱えていることを認識していたので、回避するために、JSTからUCTへの変換を処理を、標準関数を使用せずに自前で作成していた。
2. 過去のバージョンで、利用規約同意日（JST）の設定ファイルへの保存方法を変更していたのだが、その辺りの変更経緯を正しく認識していなかった。
3. したがって、バージョンアップを特定の経緯で行った（あるバージョンを飛ばすなど）環境では、開発者が想定していなかった値が設定ファイルに書き込まれていたが、気がついていなかった。
4. 想定していなかった日付をJSTからUTCに変更しようとして、エラーになって、起動しなくなっていた。
Re: (スコア:0)
失礼いたしました！
タイムゾーン周りのプラットフォーム非互換の懸念を回避するために別の手段を取ったこと原因でした。
勘違いしてました。訂正有難うございます！
Re:原因を見るとなるほどなぁ…という感想 (スコア:1)
それってクロスプラットフォームとしてのXamarinの出来が悪くて発生した不具合って事では？
MS特化な開発者が「それじゃタイムゾーンを取得してー」
TimeZoneConverter.TZConvert.GetTimeZoneInfo("Tokyo Standard Time");
Xamarinでエミュレータで動作確認！よしよし動いた動いた
ってやらかしてエラー
本来は
TimeZoneConverter.TZConvert.GetTimeZoneInfo("Asia/Tokyo");
Re: (スコア:0)
確か、以前起こっていたiOS版が初期化されるバグも、Xamarinの問題でしたよね。
https://it.srad.jp/story/21/02/15/1636231/ [it.srad.jp]
Re: (スコア:0)
WindowsとLinuxで取得するタイムゾーンの名称が異なることが原因で
エラーになっていたようですね。
まったく違います。原因はそれではありません。さてはIssueの最後に付いてるコメント [github.com]だけ斜め読みしましたね？
WindowsとLinuxで取得するタイムゾーンの名称が異なることが原因でXamarinではエラーとなるため、Microsoftのドキュメントに書かれているコードを信用せず、自前でタイムゾーンの変換処理を書いたのが原因ですよ。
ちゃんと確認するべきは自分の方では？
Re: (スコア:0)
失礼いたしました！
勘違いしてました。訂正有難うございます。出直してきます！
Re: (スコア:0)
接触確認アプリCOCOA、地域ごとの日付フォーマットの違いで利用日数が狂う新たな不具合 [srad.jp]
更新前のバージョンに依るらしい (スコア:0)
もともと潜んでた日付関係のバグらしい
COCOAにも先行ベータテスト制を導入したらどうだろうか (スコア:0)
AndroidやiOSもネイティブ開発していてもバージョンや端末によって動作不具合は起きますよ。
インストール数が相当数になっているCOCOAは先行ベータは必要だと思いますがねぇ…。
Re: (スコア:0)
Chrome CanaryとかFirefox betaみたいなやつね。
接触確認アプリは1国1アプリ制でそういうの難しいかもしれないから、段階的ロールアウトとかね。
GitHubでは先行テストするためのビルド済みのapkすら配布されてないし。
ちょっとIssue建てて来てよ。
Re: (スコア:0)
やらかしたらすぐに直せばいいっていう小規模アプリ開発者の考えが抜けてないんだろうね。
DL数3000万超の健康に関わるアプリという自覚がないから平気で貢献者に「嫌ならやめろ」とか言えちゃう。
Re: (スコア:0)
https://github.com/cocoa-mhlw/cocoa/ [github.com] にあるのはあくまでも参照実装であって実際に配布されているアプリケーションバイナリのソースコードレポジトリではないよ
どのみち、ろくに陽性登録されてないので (スコア:0)
アプリがゴミだろうと完全無欠だろうとどうでもいいわ