Skip to content

Return NOT_FOUND for missing tables and streams in the Storage Write API - #506

Open
laughingman7743 wants to merge 1 commit into
goccy:mainfrom
laughingman7743:storage-write-not-found
Open

Return NOT_FOUND for missing tables and streams in the Storage Write API#506
laughingman7743 wants to merge 1 commit into
goccy:mainfrom
laughingman7743:storage-write-not-found

Conversation

@laughingman7743

Copy link
Copy Markdown

Summary

  • getTableMetadata returns gRPC-statused NotFound errors for a missing project/dataset/table, so CreateWriteStream (and CreateReadSession, which shares the helper) answer NOT_FOUND instead of UNKNOWN
  • the unary write RPCs answer NOT_FOUND for a stream that does not exist: getOrCreateWriteStreamStatus and the FlushRows/FinalizeWriteStream lookups return statused errors, and GetWriteStream propagates the underlying error with %w instead of replacing it — so a missing table behind a _default stream name also surfaces as NOT_FOUND
  • BatchCommitWriteStreams is untouched: it already reports missing streams in-band as StorageError.STREAM_NOT_FOUND, and the streaming AppendRows error protocol is left as is

Clients implementing create-if-needed logic key on NOT_FOUND to decide to create the table; UNKNOWN reads as a transient failure, so such clients retried until their budget was exhausted and never created the table.

Fixes #504

Tests

  • go test ./server -run "TestStorageWriteMissingTableReturnsNotFound" -count=1 -v (new; red on main for all three subtests, green with this change — asserts through a real gRPC transport, so the %w-wrapped statuses are verified to survive status.FromError)
  • go test ./server -run "TestStorageWrite|TestDefaultWriteStream|TestStorageReadAVRO|TestStorageReadARROW|TestCreateReadSession|TestIssue382" -count=1
  • go test ./server

A Storage Write API RPC naming a table that does not exist surfaced as
codes.Unknown, because the handlers returned plain errors carrying no gRPC
status. Clients implementing create-if-needed logic key on NOT_FOUND to
decide to create the table; Unknown reads as a transient failure and gets
retried instead.

getTableMetadata now returns status-carrying NotFound errors for a missing
project, dataset or table (CreateReadSession shares the helper and benefits
unchanged), the stream lookups in getOrCreateWriteStreamStatus, FlushRows and
FinalizeWriteStream answer NotFound for a stream that does not exist, and
GetWriteStream propagates the underlying error with %w instead of replacing
it, so a missing table behind a _default stream name surfaces as NOT_FOUND
too. BatchCommitWriteStreams already reports missing streams in-band as
StorageError.STREAM_NOT_FOUND and is untouched, as is the streaming
AppendRows error protocol.

Fixes goccy#504
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Storage Write API: a missing table answers UNKNOWN instead of NOT_FOUND

1 participant