アカウント名:
パスワード:
連続性が担保されているデータならともかくどう途切れるか不明なデータの連続性で何か判定しようとするのは狂っている
たぶんwhile(処理件数 > 0) { 処理件数 = 送金処理(リスト#next1000件);}みたいなループなんだと思う。このループ処理の実装者と送金処理の実装者が違うなら、まぁ分からなくもないかなぁ。狂ってるというか、仕様をちゃんとチェックせずに実装しちゃった系のよくある普通のバグでしょ。
とにかく1000件読んできて、1件も処理すべき内容がなかったら終了というのがエラー検出ではなく正常な終了判定なんですかね。
不思議なのは、自動送金の処理プログラムが何件処理すべきか分かっていないということ。三菱東京UFJ銀行では、顧客から依頼されている自動送金の依頼数をコンピュータシステム上に持っていない(実際に処理してみないと分からない)ということだろうか?
# 「1度に読み込む件数を5000件に増やしたのでもう取りこぼすことはありません」となったりして。
「次のn件を取得する」みたいに、別のところからデータだけ返してくるようならありえますね。ただ万が一そんな変な連携があったとしても……まずだーっと取得して、保存して、そいつを1つ1つ処理していけば問題ないのですが。(でないとリトライするのに、またデータ受信から始まっちゃって面倒だから!)
高速化や別件対応でありそうな「正常終了判定」という印象。某都市銀行のバグ管理簿みたことあるけどテスト漏れとしか思えないバグばっかだった。「よくある普通のバグ」に全面的に賛同だわ。
> 1000件連続で「データ無し」になるとすべての処理が完了したものとして
こんな終了条件が必要なケースが思いつかないバグというより余計な処理入れてるわけで高速にもならんしスタブミスとしても不可解
うーん、ハード増強したから一括処理件数増やしたらシステムダウンとか端末で特定のミス2回連続したら無限ループとか紙伝票の余白が終了条件で余白がなければ白紙挿入という仕様で白紙が連続したら処理停止とかそういうマヌケなバグいっぱいみたんで思い付かないといわれてもありそうとしか。増税直後で何かしらシステム変更してるだろうし。1000件連続データなしはうかつだけど、一定アイドルで次の処理はあった気がする。
いやいや、トラブルが起きたのは4月30日。
三菱東京UFJ銀によると、5月1日以降の処理について、同様の事象が発生することはないという。
翌日にシステム改修が完了するなんて疑問が大きすぎる。5月分の自動送金伝票を皆で数えて、解約が1000件連続しないことを確認しただけだったりして。
> 三菱東京UFJ銀によると、5月1日以降の処理について、同様の事象が発生することはないという。
こんなの大本営発表じゃないですか。嘘でも大見得切っておかないと顧客が不安に思って逃げてしまうでしょ。
連休中に必死になって治すのでしょう。
おそらく、逐次のチェック処理だと、DBとか使わずにファイルから読み込んでるんだと思う。そしてデータの最後を表す番兵レコードがいるんじゃないかな。
そうすると、1000件単位に区切って処理しようとした場合に、全数が1001件だったりすると2単位目は対象が番兵レコード1件だけとなって、つまり処理件数0件だからループ終了みたいなへんてこ仕様なんだと思う。
で、テストでもその条件でループ終了することを確認してOK、みたいな。そうだとしたら設計が良くないし、ついでに設計者同士の連携も良くないんでしょう。
番兵レコードの存在を知らなかったんじゃないかな。きっと、EOFを過ぎてファイルからバッファに1000件分読み込んで処理を行うと処理件数が0に(偶然に)なることを利用して、EOFを過ぎたことを検出して終了するようなプログラムを書いていたのではないかと思った。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
物事のやり方は一つではない -- Perlな人
話にならない (スコア:0)
連続性が担保されているデータならともかく
どう途切れるか不明なデータの連続性で何か判定しようとするのは狂っている
Re:話にならない (スコア:3)
たぶん
while(処理件数 > 0) {
処理件数 = 送金処理(リスト#next1000件);
}
みたいなループなんだと思う。
このループ処理の実装者と送金処理の実装者が違うなら、まぁ分からなくもないかなぁ。
狂ってるというか、仕様をちゃんとチェックせずに実装しちゃった系のよくある普通のバグでしょ。
Re:話にならない (スコア:1)
とにかく1000件読んできて、1件も処理すべき内容がなかったら終了というのが
エラー検出ではなく正常な終了判定なんですかね。
不思議なのは、自動送金の処理プログラムが何件処理すべきか分かっていないということ。
三菱東京UFJ銀行では、顧客から依頼されている自動送金の依頼数をコンピュータシステム上に
持っていない(実際に処理してみないと分からない)ということだろうか?
# 「1度に読み込む件数を5000件に増やしたのでもう取りこぼすことはありません」となったりして。
Re:話にならない (スコア:2)
日次で同じ程度の件数が上がってくるシステムやったけど、確実に終わりはあったけど。
Re:話にならない (スコア:1)
「次のn件を取得する」みたいに、別のところからデータだけ返してくるようならありえますね。
ただ万が一そんな変な連携があったとしても……まずだーっと取得して、保存して、そいつを1つ1つ処理していけば問題ないのですが。(でないとリトライするのに、またデータ受信から始まっちゃって面倒だから!)
==========================================
投稿処理前プレビュー確認後書込処理検証処理前反映可否確認処理後……
Re: (スコア:0)
高速化や別件対応でありそうな「正常終了判定」という印象。
某都市銀行のバグ管理簿みたことあるけどテスト漏れとしか思えないバグばっかだった。
「よくある普通のバグ」に全面的に賛同だわ。
Re: (スコア:0)
> 1000件連続で「データ無し」になるとすべての処理が完了したものとして
こんな終了条件が必要なケースが思いつかない
バグというより余計な処理入れてるわけで
高速にもならんしスタブミスとしても不可解
Re: (スコア:0)
うーん、ハード増強したから一括処理件数増やしたらシステムダウンとか
端末で特定のミス2回連続したら無限ループとか
紙伝票の余白が終了条件で余白がなければ白紙挿入という仕様で白紙が連続したら処理停止とか
そういうマヌケなバグいっぱいみたんで思い付かないといわれてもありそうとしか。
増税直後で何かしらシステム変更してるだろうし。
1000件連続データなしはうかつだけど、一定アイドルで次の処理はあった気がする。
Re: (スコア:0)
# 「1度に読み込む件数を5000件に増やしたのでもう取りこぼすことはありません」となったりして。
いやいや、トラブルが起きたのは4月30日。
三菱東京UFJ銀によると、5月1日以降の処理について、同様の事象が発生することはないという。
翌日にシステム改修が完了するなんて疑問が大きすぎる。
5月分の自動送金伝票を皆で数えて、解約が1000件連続しないことを確認しただけだったりして。
Re: (スコア:0)
> 三菱東京UFJ銀によると、5月1日以降の処理について、同様の事象が発生することはないという。
こんなの大本営発表じゃないですか。
嘘でも大見得切っておかないと顧客が不安に思って逃げてしまうでしょ。
連休中に必死になって治すのでしょう。
Re:話にならない (スコア:1)
おそらく、逐次のチェック処理だと、DBとか使わずにファイルから読み込んでるんだと思う。
そしてデータの最後を表す番兵レコードがいるんじゃないかな。
そうすると、1000件単位に区切って処理しようとした場合に、全数が1001件だったりすると
2単位目は対象が番兵レコード1件だけとなって、つまり処理件数0件だからループ終了
みたいなへんてこ仕様なんだと思う。
で、テストでもその条件でループ終了することを確認してOK、みたいな。
そうだとしたら設計が良くないし、ついでに設計者同士の連携も良くないんでしょう。
Re: (スコア:0)
番兵レコードの存在を知らなかったんじゃないかな。きっと、EOFを過ぎてファイルからバッファに1000件分読み込んで処理を行うと処理件数が0に(偶然に)なることを利用して、EOFを過ぎたことを検出して終了するようなプログラムを書いていたのではないかと思った。