test(e2e): fix 4 pre-existing nightly failures (swap/clone/stream/config-secret)#521
Merged
Conversation
…fig-secret) These four failed on the nightly independently of the expired-token outage (#518) and of the v0.75.0 release. Each is a test-side defect or an environment/consistency quirk, not a product regression -- all verified live against project 5946 on 2026-07-22. No source behavior changes. - clone (test_clone_prod_table_into_dev_branch): STEP 1 created a table on the DEFAULT branch without first creating its bucket. create-table auto-creates the bucket only in a dev branch (to materialize the branch's isolated storage); on the production path the bucket must exist. Added the missing create-bucket step. - config-secret (test_config_create_and_update_encrypt_secret): _read_password indexed data["configuration"], but _run_ok returns the full {status, data} envelope, so the config body is at data["data"]["configuration"]. Corrected the path. - swap (test_swap_in_dev_branch_exchanges_schemas): the swap is correct, but the test read the raw /tables/{id} `definition.columns` block, which is read-after-DDL eventually consistent on this stack -- it kept reporting the pre-swap length for >30s. The CLI's normalized `column_details` reflects the swap immediately, so the test now reads lengths via `storage table-detail` (with a short safety poll), matching what a user/agent actually sees. - stream (test_stream_otlp_e2e): the fixed source name `kbagent-e2e-stream` had a wedged server-side delete task (unremovable via the API), and --if-not-exists reused it every run, so cleanup could never succeed. Use a unique per-run source name (fresh sources create+delete in ~3s), tolerate a retryable TIMEOUT on delete by confirming eventual removal via a polled list, and best-effort drop the auto-provisioned sink bucket that lingers after the source is gone. make check green (4648 passed). Test-only diff.
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
padak
added a commit
that referenced
this pull request
Jul 22, 2026
…523) Follow-up to #521. Poll the tag-filtered Files list until the just-uploaded file appears (bounded ~30s) instead of asserting the first read, in both the SDK-facade round-trip and the CLI file-ops flow. The upload is durable; only the tag index lags (read-after-write eventually consistent). Test-only; make check green.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes the 4 pre-existing nightly E2E failures that remained red after the
E2E_API_TOKENrotation (#518). None are product regressions or related to v0.75.0 — each is a test-side defect or an environment/consistency quirk. All diagnosed by reproducing live against the E2E project (5946) on 2026-07-22. Test-only diff; nosrc/behavior changes.Before:
4 failed, 111 passed. After (all four, live):4 passed.Root causes & fixes
test_clone_prod_table_into_dev_branchcreate-tableauto-creates the bucket only in a dev branch (to materialize the branch's isolated storage); the production path needs it to exist. (The swap test gets away with it because it creates with--branch.)create-bucketstep.test_config_create_and_update_encrypt_secret_read_passwordindexeddata["configuration"], but_run_okreturns the full{status, data}envelope — the config body is atdata["data"]["configuration"].test_swap_in_dev_branch_exchanges_schemas/tables/{id}definition.columnsblock, which is read-after-DDL eventually consistent on this stack — it kept reporting the pre-swap length for >30s. The CLI's normalizedcolumn_detailsreflects the swap immediately.storage table-detail→column_details(what a user/agent sees), with a short safety poll.test_stream_otlp_e2ekbagent-e2e-streamhad a wedged server-side delete task (unremovable via the API — confirmed: stillprocessingafter 5+ min, even after removing its sink bucket), and--if-not-existsreused it every run, so cleanup could never succeed.TIMEOUTon delete by confirming eventual removal via a polled list; best-effort drop the lingering sink bucket.Why test-side, not product
column_details(the field the CLI/SDK surface) is immediately consistent after a swap in every repro; only the rawdefinition.columnsblock lags. So the product output users consume is correct — the test was reading a laggy internal field.STREAM_TASK_TIMEOUT— there's no evidence a legitimate delete needs longer, and the tolerant-cleanup + list-poll already covers a hypothetical slow-but-successful delete.Verification
4 passed in 92s).make checkgreen (4648 passed, 8 skipped).in.c-otlp-*sink buckets from prior runs. The wedgedkbagent-e2e-streamsource itself is unremovable via the API and remains as an orphan — it needs platform cleanup, but with the unique-name fix it no longer blocks the test.Note for maintainers
The wedged
kbagent-e2e-streamStream source on project 5946 cannot be deleted through the API (delete task hangs indefinitely). It's harmless now (the test no longer references it) but may warrant a platform-side cleanup.