M5a E2E: CreateTable returns ACTIVE but DescribeTable / GetItem / ListTables silently see no data under --shardRanges-only routing

[bootjp]

症状

scripts/run-jepsen-m5-local.sh 実行時 (PR #924/#925 マージ後)、dynamodb-append-multi-table-workload が全 worker txn で ResourceNotFoundException: table not found を返す。

再現条件

--shardRanges のみで明示的な ranges を指定し、デフォルト range [<empty>, +inf) がない multi-group cluster:

$BINARY \
  --raftBootstrap \
  --raftGroups   "1=127.0.0.1:50051,2=127.0.0.1:50054" \
  --shardRanges  "<T1_KEY>:<T3_KEY>=1,<T3_KEY>:=2" \
  ...

直接 curl での再現 (workload を経由しない最小ケース)

1. CreateTable jepsen_append_t1 → 200 OK, "TableStatus":"ACTIVE"
2. DescribeTable jepsen_append_t1 → ResourceNotFoundException
3. PutItem → ResourceNotFoundException
4. GetItem → ResourceNotFoundException
5. ListTables → {"TableNames":[]} ← 空配列!

つまり CreateTable は成功 response を返すが、続く全 read で table が見えない。

根本原因の仮説 (未確定)

adapter/dynamodb.go:782-806 の createTable handler は d.coordinator.Dispatch(req) の戻り値 err が nil なら "ACTIVE" を返す。

makeCreateTableRequest の write set:

• dynamoTableMetaKey(tableName) = !ddb|meta|table|<base64> → routing key !ddb|route|table|<base64> = T1_KEY → group 1
• dynamoTableGenerationKey(tableName) = !ddb|meta|gen|<base64> → 同じ routing → group 1

両方とも group 1 に行く single-shard txn。 これが Dispatch 成功 (err=nil) を返している。

しかし、続く loadTableSchema (read path):

• d.store.GetAt(dynamoTableMetaKey(tableName), ts) で同じ key を読む
• ShardStore.GetAt → groupForKey → group 1 の store
• 同じ group なのに ErrKeyNotFound 返却

ListTables も空 → commit が durable に store に反映されていない か route range 外として scan/get が除外している 可能性。

確認済み

• ✅ ListRoutes は正常な 2-group catalog を返す
• ✅ /tmp/elastickv-debug/n1/n1/group-{1,2}/fsm.db 両方のディレクトリは存在
• ❌ サーバログに CreateTable / dispatch / error trace は一切なし (INFO level の制約か)

推測される影響範囲

• --shardRanges を非デフォルトで指定する全シナリオ
• 既存の single-group デフォルト routing (run-jepsen-local.sh の 3-node 構成) は影響なし (デフォルト range [<empty>, +inf) あり)

関連 PR

• feat(cmd): M5a — elastickv-split + elastickv-route-key CLI tools #911 / feat(jepsen): M5a — dynamodb-append-multi-table-workload #916 / feat(scripts): M5a — run-jepsen-m5-local.sh single-process two-group launcher #924 / feat(jepsen): M5a — setup-hook verification + elastickv-list-routes CLI #925: Composed-1 M5a 実装
• fix(scripts): M5a — --host 127.0.0.1 for --local mode #926: --host 127.0.0.1 fix (E2E 中に発見)
• 2026_06_02_partial_composed1_m5_jepsen_route_shuffle.md: Status section に本 issue を follow-up として記載済み

次のステップ

調査が必要:

1. CreateTable dispatch 後、実際に group 1 の pebble db に何が書かれたか確認 (pebble の low-level inspector が必要)
2. ShardStore.ScanAt の挙動が --shardRanges 内のキーのみ返すか (default-range 不在で scan boundaries が壊れる可能性)
3. もしくは loadTableSchema の snapshotTS 計算が新しい write を見えない TS を返している可能性

実装の方向性:

• (a) parseShardRanges でデフォルト range を補完して --shardRanges 外の routing を可能にする
• (b) ShardStore 側で scan の boundary handling を修正
• (c) CreateTable dispatch の commit ack を待つように adapter を修正

[bootjp]

根本原因の特定が前進

adapter/dynamodb.go の createTable handler に debug println を追加し、Dispatch 直後に直接 d.store.GetAt(metaKey, consistentReadLatestTS) で確認:

[#930-debug] post-create GetAt(metaKey="!ddb|meta|table|Y2hlY2tfdGFibGU", consistentReadLatestTS) -> len(bytes)=0, err=not found
[#930-debug] post-create GetAt(metaKey, LastCommitTS=1) -> len=0, err=not found

確定事項

1. d.coordinator.Dispatch(req) は err=nil で return → createTable handler は ACTIVE を返す
2. しかし directly 直後の d.store.GetAt(metaKey, consistentReadLatestTS) で not found
3. d.store.LastCommitTS() == 1 (= 全 group の初期値) — つまり どの group の store にも commit が一切走っていない

仮説の改訂

#	仮説	結果
1	stale snapshotTS	❌ rejected (consistentReadLatestTS でも not found)
2	Dispatch が commit を待たない	🟡 partially: 待ってるが何も commit していない
3	ShardStore.ScanAt の boundary	❌ rejected (direct GetAt も not found)
4	--shardRanges coverage 不足	❌ rejected (routing key は T1_KEY 範囲内)
5	Dispatch silently succeeds without writing	✓ 強く示唆

次の調査方向

kv/sharded_coordinator.goの Dispatch メソッドで:

• IsTxn: true + StartTS: 0 のパスで何かが skip
• groupMutations が空の txn を return
• dispatchTxn 内で何かしらの early return

createTable の req は:

&kv.OperationGroup[kv.OP]{
    IsTxn:   true,
    StartTS: 0,
    Elems: []*kv.Elem[kv.OP]{
        {Op: kv.Put, Key: dynamoTableMetaKey(name), Value: schemaBytes},
        {Op: kv.Put, Key: dynamoTableGenerationKey(name), Value: ...},
    },
}

両方の Key が同じ routing key (T1_KEY) に正規化されて group 1 へ。 → dispatchSingleShardTxn(group=1) のはず。 そこで何かが起きている。

(Adapter debug println は branch fix/m5a-local-host には commit していない。後でクリーンアップ予定。)

[bootjp]

🎯 ROOT CAUSE 特定

ShardedCoordinator.dispatchTxn に debug println を追加して走査:

[#930] attempt=0 StartTS=116691960705777664 CommitTS=0 PrevCommitTS=0 numElems=2 ObservedVer=1
[#930] dispatchTxn ret resp=<nil> err=no route for key "!ddb|meta|table|Y2hlY2tfdGFibGU": invalid request
[#930-debug] post-create GetAt(metaKey="!ddb|meta|table|Y2hlY2tfdGFibGU", consistentReadLatestTS) -> len(bytes)=0, err=not found

確定された事象

dispatchTxn が "no route for key" エラーを返している。 Y2hlY2tfdGFibGU = base64("check_table")。

Routing 分析

• check_table の routing key = !ddb|route|table|Y2hlY2tfdGFibGU
• T1_KEY = !ddb|route|table|amVwc2VuX2FwcGVuZF90MQ (base64(jepsen_append_t1))
• ASCII 比較: Y (89) < a (97) — つまり check_table の routing key < T1_KEY
• --shardRanges で [T1_KEY, T3_KEY)=1, [T3_KEY, +inf)=2 のみ指定。[<empty>, T1_KEY) の範囲には route が無い
• → engine.GetRoute() で (Route{}, false) → ResolveGroup で (0, false) → no route for key

矛盾 (要追加調査)

それでも HTTP response は ACTIVE を返している。 createTableWithRetry のロジック:

if _, err := d.coordinator.Dispatch(ctx, req); err == nil {
    return nil
}
if !isRetryableTransactWriteError(err) {
    return errors.WithStack(err)
}

no route for key が isRetryableTransactWriteError で retryable と判定されている可能性。 そうだと、 retry loop で transactRetryMaxAttempts 回 retry → 最後に "create table retry attempts exhausted" を返すはず。 しかし debug log では attempt=0 のみ表示で、再度の dispatch が無い。 何かの silent swallow が起きている。

対処方針

1. 短期 (M5a unblock): Launch script で --shardRanges をデフォルト range :T1_KEY=1 でカバー
2. 本質的: jepsen テーブル名以外の routing key (e.g. dummy 名で create する場合) も含めた routing 設計が必要
3. adapter 層: createTableWithRetry の error handling を見直し (no route が ACTIVE response になる silent swallow バグ)

Jepsen workload との関係

Jepsen workload は jepsen_append_t1..t4 だけ create するので、 routing key は すべて T1_KEY ≤ x で group 1 or 2 にルートされる範囲内。 つまり check_table のような外れ値テスト以外では routing fail はしないはず。 にも関わらず workload が all-fail だったのは、Adapter 層で別の問題 (おそらく ListTables の scan が空 → 全 GetItem も失敗) が起きている。

次のステップ

ListTables の実装と ShardStore.ScanAt の挙動を確認。これが原因なら、"--shardRanges 内のテーブル名なら作成は成功するが、 ListTables/scan が範囲外の prefix も含めて scan できず、 結果として ListTables = []" という症状の説明がつく。

[bootjp]

第 2 の bug が存在

[<empty>, T1_KEY) を --shardRanges に追加して全 routing key をカバーした (PR #926 の 83d44c0)。 これで "no route for key" は解消されるはず。

しかし E2E 走らせると依然 workers が all-fail (ResourceNotFoundException):

INFO [...] jepsen worker 0 - jepsen.util 0	:info	:txn	[[:append 10 1]]	DynamoDB ResourceNotFoundException: table not found
INFO [...] jepsen worker 1 - jepsen.util 1	:info	:txn	[[:r 10 nil] [:r 9 nil]]	DynamoDB ResourceNotFoundException: table not found
...

解析

jepsen_append_t1..t4 の routing key は amVwc2VuX2FwcGVuZF90MQ..NA で 元々 [T1_KEY, +inf) のカバー範囲内。 つまり routing 修正の恩恵を受けるべきテーブルではない。 これらのテーブルがそもそも create できていなかった?

仮説候補

1. 5 並列 setup! の race: 全 5 client が並列 create-all-tables! を呼ぶ → 内部で race condition → 全部失敗するが ResourceInUseException で catch されて成功 report
2. createTableWithRetry の silent swallow: 何かのエラーが "ACTIVE" として返されている (DescribeTable 試したらバラバラ)
3. table generation の race: nextTableGenerationAt が race して increment が衝突

次のステップ

• 単一 client (concurrency=1) で同じ workload を走らせて race を排除し、 fix の効き目を切り分け
• dispatchTxn の戻り値を adapter 側で全件 log 出力 ("silent swallow" の特定)
• tableLocks (adapter/dynamodb.go:135) が cross-client で機能するか確認 (per-server プロセスなので OK のはずだが)

[bootjp]

✅ ROOT CAUSE 完全特定 + FIX 完成 (PR #932)

adapter/dynamodb.go の createTableWithRetry に詳細 debug println を追加して走査:

[#930-ctr] table=jepsen_append_t3 attempt=0 Dispatch -> resp=<nil> err=observed-version v=1:
  key "!ddb|meta|table|amVwc2VuX2FwcGVuZF90Mw" owned by group 1 (found=true);
  this FSM serves group 2: composed-1: route ownership shifted; retry on new owning group

True root cause

kv/fsm.go:639 verifyOwnerFromSnapshot が raw mutation key で OwnerOf を呼んでいる。 OwnerOf の routes[].Start / routes[].End は routing key (!ddb|route|...) の形なので:

• !ddb|meta|table|... (raw) は ASCII で !ddb|route|table|... (routing) より lexicographically 小
• 結果: 全 !ddb|meta|... キーが間違って group 1 へ "fall"
• 実際の Dispatch は engine.GetRoute(routeKey(rawKey)) で正しく group 2 へ送る
• → Dispatch と verify で不整合 → spurious ErrComposed1Violation

Fix (PR #932)

snap.OwnerOf(routeKey(mut.Key)) で normalize して比較。 ShardRouter.ResolveGroup / ShardStore.GetAt と同じ semantic に揃える。

Verification

./scripts/run-jepsen-m5-local.sh で:

results.edn: {:valid? true}

Workers が txn 正常完了、 read で先行 append を全て確認、 ResourceNotFoundException 完全解消。

Closing once #932 merges.