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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
WARNING: New copy says downloads expire after 24 hours, but the backend still expires exports 7 days after completion
When an export completes, the user-data-export worker sets
expires_at = now() + interval '7 days'(services/user-data-export/src/databases.ts:117), and the presigned download URL TTL is derived from thatexpires_at(services/user-data-export/src/index.ts,downloadExpiration). This PR changes only the UI copy, so after merge the page will tell users downloads expire in 24 hours while they actually remain available for 7 days. If the intent is a real 24-hour expiry, the worker change needs to ship with (or before) this copy; otherwise the copy should stay at 7 days. Note: the 24-hour figure matches the separate re-request throttle (apps/web/src/routers/user-exports-router.ts: "You can request one data export every 24 hours"), which is a different limit.Reply with
@kilocode-bot fix itto have Kilo Code address this issue.