trunk-merge/pr-1169/729fbd12-a75c-47c3-878a-c038f20abe71 - #1177
Closed
trunk-io[bot] wants to merge 5 commits into
Closed
trunk-merge/pr-1169/729fbd12-a75c-47c3-878a-c038f20abe71#1177trunk-io[bot] wants to merge 5 commits into
trunk-io[bot] wants to merge 5 commits into
Conversation
…s passed The end-of-run "Bundle Upload ID" line becomes a link when the run is in test-collection link mode: 🏷️ Bundle Upload: https://app.trunk.io/{org}/flaky-tests/collections/{short_id}/u/{bundle_meta_id} The webapp resolves the upload's createdAt from the id and redirects to the canonical uploads page (companion PR: trunk-io/trunk2#5440). Unlike the per-test `/t/` links there is no `?repo=` param — the collection short id fully scopes the lookup. Gated exactly as the `/t/` links are: a collection id must be passed and `--hide-test-collection-links` / `TRUNK_HIDE_TEST_COLLECTION_LINKS` must be unset. Otherwise the bare bundle upload id prints as before. The gate reads `test_collection_short_id` rather than `base_props.test_collection.short_id` because an exported-but-blank `TRUNK_TEST_COLLECTION_ID` is `Some("")`, not `None`, and would otherwise produce a malformed `/collections//u/` link. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…solve Alternative to the short-link form in #1168, for comparison — see trunk-io/trunk2#5440. The short link carries only the bundle_meta id, so the webapp has to recover `bundle_meta_created_at` before it can address the upload, then redirect. That lookup cannot use `test_collection_upload`'s primary key: it leads with `(test_collection_id, repo_id, bundle_meta_created_at, …)` and a link carries no repo, so with `repo_id` unconstrained the index resolves only the leading column and every granule in the collection becomes a bloom-filter candidate. The 45-day TTL means the query's own 45-day bound prunes almost nothing on top of that. It measures as one granule on staging today only because staging collections fit in one granule. The CLI already has both halves — `CreateBundleUploadResponse` returns `test_collection_bundle_meta_created_at` alongside the id, and both land in the bundle — so it can emit the webapp's canonical `uploads/{bundleMetaKey}` URL directly and skip the lookup and the redirect entirely. Costs, stated plainly: - The printed URL grows from 105 to 170 characters (+62%), which is the tradeoff the short-link design was chosen to avoid. - It makes the CLI a second producer of the `bundleMetaKey` encoding, a frozen contract with `encodeBundleMetaKey` in trunk2. Pinned here by a golden vector generated from that function. Mitigating: `bundleMetaKey` is already a permanent public URL contract the webapp emits, and unlike a hash its drift is visible — it is base64 of a two-field JSON object. Field order and whitespace match `JSON.stringify({ id, createdAt })` byte for byte via a `Serialize` struct rather than a `format!`, so the golden test is meaningful and an id containing a quote cannot break the payload. The webapp's decoder parses JSON and is order-insensitive, so a drift would still resolve — it would just stop matching the string the webapp emits. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The golden vector now uses a case verified three ways: against a base64 of the literal JSON, against trunk2's own `encodeBundleMetaKey`, and by decoding the Rust output back (byte-identical, field order and no-whitespace included). Confirmed load-bearing — swapping the struct's field order fails it. The three url_for_upload cases shared five identical arguments; they go through one `upload_url(created_at)` helper so each test shows only what it varies. Comments trimmed to the non-obvious parts. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #1177 +/- ##
==========================================
+ Coverage 83.05% 83.37% +0.32%
==========================================
Files 72 72
Lines 16313 16375 +62
==========================================
+ Hits 13549 13653 +104
+ Misses 2764 2722 -42 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
|
Author
trunk-io
Bot
deleted the
trunk-merge/pr-1169/729fbd12-a75c-47c3-878a-c038f20abe71
branch
August 27, 2026 19:15
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
2 participants
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.
This pull request was created and is being managed by Trunk Merge.
This pull request is based on the main branch at SHA 0b76b8d2a3313bb25a5312ca2a09b76a6aac3dd5.
See more details here.
When CI completes, this pull request will be closed automatically.
Pull Requests Being Tested
This pull request is testing the changes from pull request 1169, stacked on pull request 1168.