[ismailbarankarasu]

What changed

• Added GET /api/sessions/{id}/events/download to download a session's fixed events.json activity log as an attachment.
• Added a Download log action beside the Activity heading on the session details page.
• Used a clear attachment filename in the session-{id}-events.json format.
• Added endpoint tests covering:
  • Successful activity-log download
  • Missing events.json file
  • Missing session
• Returns 404 Not Found when the session or activity log does not exist.

Closes #9

Verification

• dotnet test passes
• dotnet format --verify-no-changes passes
• No credentials, camera images, logs, or generated videos are included
• Documentation is updated when behavior changes

Security impact

The endpoint does not accept a user-controlled filename or path. It resolves the validated session directory through ICaptureSessionService and only accesses the fixed events.json file inside that directory.

The endpoint returns 404 Not Found when the session or file is unavailable. No changes were made to URL validation, network access, credentials, FFmpeg execution, or the application's existing access-control defaults.

[elkampu]

Thanks for taking this on—the download action, NDJSON content type, and streaming approach are a good start. I found two blocking issues that need to be addressed before this can merge:

1. The app writes and reads the activity log as events.jsonl in FrameCatalogService (write, read), but the new endpoint looks for events.json and returns a .json attachment (lines 139–160). Real session downloads will therefore return 404. Please use events.jsonl for both the stored path and download filename.

2. The patch replaces the existing GET /api/sessions/{id}/events endpoint (original mapping) with /events/download (new mapping). That unintentionally removes the existing JSON API and its limit behavior. Please keep the original route unchanged and register the download route alongside it.

The success test currently writes events.json directly (lines 45–49), so it mirrors the implementation typo instead of exercising production behavior. Please seed the log through IFrameCatalogService.AppendEventAsync (or at minimum write the actual events.jsonl), assert a .jsonl attachment name, and add a regression test confirming the original /events endpoint still works.

Once those are fixed, I will be happy to re-review. Thank you for the contribution!

[ismailbarankarasu]

Thanks for the detailed review. I have addressed the requested changes:

• Restored the existing GET /api/sessions/{id}/events endpoint and its limit behavior.
• Updated the download endpoint to use the actual events.jsonl file and a .jsonl attachment filename.
• Updated the success test to seed the log through IFrameCatalogService.AppendEventAsync.
• Added a regression test confirming that the original events endpoint remains available.

All 48 tests are passing, including the four activity-log endpoint tests.

[ismailbarankarasu]

Hi @elkampu, just following up on the requested changes. The fixes have been pushed, all 48 tests pass locally, and the PR is ready for re-review. The GitHub Actions workflows are also still awaiting maintainer approval.

When you have a chance, could you please take another look and approve the workflows? Thank you!

[elkampu]

Re-review complete. The endpoint now preserves the existing event API, streams the actual events.jsonl log with the correct content type and attachment name, and covers the regression path. Clean Release build, all 48 tests, and formatting checks pass locally. Thank you for the careful follow-up.