[BUG] Worker share-link re-mint invalidates previously copied floom.dev/s URLs

[federicodeponte]

Summary

Worker standalone share links created by POST /workers/{id}/share-link are create-or-rotate. Calling the endpoint again invalidates the previously copied https://floom.dev/s/<token> URL, so users who already pasted the link see a 404 later.

This made the Gmail Inbox Cleaner launch link appear broken: an earlier verified URL later returned 404 after a newer share-link POST minted a replacement token.

Reproduction

Using cloud worker gmail-inbox-cleaner-public in workspace cloud-ws_d8cff133674548:

1. Mint a worker share link:
   POST https://workeros-api.floom.dev/api/workers/gmail-inbox-cleaner-public/share-link
2. Open the returned https://floom.dev/s/<token>.
3. Confirm it returns HTTP 200 and renders Gmail Inbox Cleaner (public template).
4. Mint the share link again for the same worker.
5. Re-open the first copied URL.

Actual

The first URL returns HTTP 404 from both:

• https://floom.dev/s/<old-token>
• https://workeros-api.floom.dev/api/s/<old-token> with {"detail":"Short link not found"}

The newest URL works. Verified current behavior with a fresh latest token:

• page: HTTP 200, final URL under /app/s/<token>, contains Gmail Inbox Cleaner and gmail-inbox-cleaner-public
• API: HTTP 200, returns entity_type=worker
• repeated delayed checks at ~0s, ~20s, ~80s, and ~200s stayed HTTP 200 as long as the link was not re-minted

Expected

One of these product behaviors:

• POST /workers/{id}/share-link returns the existing active URL unless the user explicitly revokes/regenerates it, or
• the UI/CLI labels the action as “regenerate link” and warns that existing copied URLs stop working, or
• old tokens remain valid until explicit revoke.

For public worker templates, the current create-or-rotate behavior is risky because users naturally click/copy/share multiple times while preparing launch materials, invalidating links already pasted into posts, docs, or emails.

Related

This is the worker-share version of the same class of issue tracked for batch approval share links in #1965.

Verification Already Run

Worker bundle itself is not the blocker:

• npx -y @floomhq/floom@latest workers validate /tmp/gmail-inbox-cleaner-audit-isolated passed
• python3 -m py_compile run.py passed in isolated bundle
• isolated smoke test confirmed test mode makes no Gmail mutations
• PYTHONPATH=apps/api python3 -m pytest apps/api/tests/test_standalone_share_public.py apps/api/tests/test_share_link_revoke.py tests/test_gmail_inbox_manager_plus.py -q passed: 10 tests

OpenCode/Gemini audit also inspected the isolated bundle. Its Gmail OAuth-scope warning was a false positive for Floom's manifest model: Composio access is constrained via connections[].allowed_tools; narrower OAuth requires a separate Composio auth config.

[federicodeponte]

Implemented in PR #2148: #2148

Fix details:

• re-sharing a worker now mints an additional active token instead of overwriting the old token hash
• explicit revoke still removes all active tokens for that shared entity
• standalone share URLs are forced to floom.dev when configuration accidentally points at API hosts such as workeros-api.floom.dev
• public worker shares now include sharer metadata plus overview/source/setup panes with copy/download actions

Production caveat: any already-overwritten hash-only token cannot be recovered because the raw token was never stored. After this is deployed, the Gmail inbox cleaner worker needs to be shared again to create a fresh floom.dev/s/... URL.

[federicodeponte]

Merged in #2148 as c9ba295. Post-merge main CI passed: Python lint, dependency review, secret scan, web lint/unit tests, MCP tests, and runtime tests on Ubuntu + Windows.

Remaining operational step: mint a new Gmail inbox cleaner public share after production deploy picks up this commit. Previously overwritten hash-only URLs, including fls_EuvSRoRLkeNe410bt8S5E6Wb, still cannot be restored because the raw token was not stored.