feat(upload): print the canonical upload link, not a short link to resolve

[TylerJang27]

Replaces the need for https://github.com/trunk-io/trunk2/pull/5440

What this changes

#1168 prints …/collections/{shortId}/u/{bundleMetaId}, and trunk2#5440 adds a page that resolves the upload's bundle_meta_created_at from that id and redirects to the canonical …/collections/{shortId}/uploads/{bundleMetaKey}.

This prints the canonical URL directly. The CLI already has both halves: CreateBundleUploadResponse returns test_collection_bundle_meta_created_at next to the id, and both land in the bundle as TestCollectionProps. So there is nothing to look up.

before  105 chars  …/collections/tc_a1b2c3d4/u/82c6a6e5-f8ea-4d93-9a26-b8ab6ff8f6bc
after   170 chars  …/collections/tc_a1b2c3d4/uploads/eyJpZCI6IjgyYzZhNmU1LWY4ZWEtNGQ5My05YTI2LWI4YWI2ZmY4ZjZiYyIsImNyZWF0ZWRBdCI6MTc3ODQxNjQ5NjAwMH0

Why it might be worth the longer URL

The resolve the short link requires cannot use test_collection_upload's primary key. That key leads with (test_collection_id, repo_id, bundle_meta_created_at, …); a link carries no repo, so with repo_id unconstrained the index resolves only the leading column and every granule in the collection is a bloom-filter candidate. The table's 45-day TTL also means the query's own 45-day bound prunes almost nothing beyond what the TTL already did.

It measures at one granule (8,192 rows) on staging only because staging collections fit in one granule — that is a floor, not a scaling result. At the volumes prod is heading for, it becomes a multi-MB skip-index read per click.

Why it might not be

• The longer URL is the thing the short-link design exists to avoid. If a short, pasteable link is the product requirement, this is the wrong trade and the fix belongs server-side (a bundle_meta_id-ordered projection on test_collection_upload makes the resolve a point read; cheapest to add before the table fills up).
• It makes the CLI a second producer of the bundleMetaKey encoding — a frozen cross-repo contract with encodeBundleMetaKey in trunk2. That is the same class of coupling that caused the bundle_meta_id divergence in trunk-io/trunk2#5451. Mitigating: bundleMetaKey is already a permanent public URL contract the webapp emits, so it is frozen either way, and unlike a hash its drift is visible — it is base64 of a two-field JSON object.
• The redirect has a benefit of its own: it leaves the canonical URL in the address bar, so a refresh, bookmark, or forwarded link never re-pays the resolve. This form gets that too (it is the canonical URL), so this is only an argument against rendering the short link in place — noting it for completeness.

Implementation notes

• The key is built from a #[derive(Serialize)] struct, not a format!, so field order and whitespace match JSON.stringify({ id, createdAt }) byte for byte and an id containing a quote cannot break the payload.
• Golden vector in api/src/urls.rs generated from trunk2's encodeBundleMetaKey; the CLI integration test's expectation is generated the same way.
• base64 and chrono become direct deps of api — both were already in the lock, so the lock diff is two lines.
• url_for_upload returns anyhow::Result now, since parsing the timestamp is a second failure mode. The caller already discarded errors with .ok(), so a malformed timestamp degrades to printing no link rather than a broken one.

Testing

• api: golden vector, offset-independence (…18:16:48.873Z and …11:16:48.873-07:00 must produce the same key), and an unparseable-timestamp rejection — 5 passed
• trunk-analytics-cli --test upload: 53 passed, including the three link assertions
• Full workspace: 54 test targets, 0 failures. cargo clippy --all-targets clean; cargo fmt clean for every file this touches (the one pre-existing diff in context/src/junit/parser.rs is on the base branch too)

[trunk-staging-io]

   

Failed Test	Failure Summary	Logs
pending_quarantine_test should be quarantined when run with variant	A test marked as pending was expected to fail but unexpectedly passed.	Logs ↗︎
variant_quarantine_test should be quarantined when run with variant	A test expected the sum of 2 + 2 to be 5, but it was actually 4, indicating a failing assertion.	Logs ↗︎

View Full Report ↗︎ ⋅ Docs

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 83.37%. Comparing base (ca5d99b) to head (1bb9913).

Additional details and impacted files

@@                          Coverage Diff                           @@
##           tyler/collection-upload-short-link    #1169      +/-   ##
======================================================================
+ Coverage                               83.36%   83.37%   +0.01%     
======================================================================
  Files                                      72       72              
  Lines                                   16359    16375      +16     
======================================================================
+ Hits                                    13637    13653      +16     
  Misses                                   2722     2722              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[trunk-io]

   

View Full Report ↗︎ ⋅ Docs