Update Scheduled Mail Handler

[sevivenegas]

References

• Linear:

Proposed Changes

Summary

Implemented the handler to update a scheduled mail, allowing users to modify when a scheduled email will be sent.

Changes

• Added logic to update scheduled send time in the backend
• Integrated update functionality into existing mail handler

Notes

• Needs to be tested as I could not on my laptop

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
mail	Ready	Preview, Comment	Apr 2, 2026 1:36am

In general, the fix is to add an explicit permissions block that restricts the GITHUB_TOKEN to the minimal scope required. For pure linting jobs that only need to read repository contents, contents: read is sufficient. Since both run-linters and ruff are lint jobs and do not perform write operations to the repo or GitHub APIs, they can share a global minimal permissions block.

The best way to fix this without changing existing functionality is to add a top-level permissions block after the on: trigger. This will apply to all jobs (including ruff) that don’t define their own permissions. We’ll set contents: read, which is the minimal recommended starting point and matches CodeQL’s suggestion. No imports or additional methods are needed; this is entirely a YAML configuration change in .github/workflows/lint.yml, within the shown snippet.

Concretely, in .github/workflows/lint.yml, insert:

permissions:
    contents: read

between lines 2 and 3 (after on: pull_request and before jobs:), maintaining the existing indentation style.

In general, this should be fixed by ensuring that detailed exception information (including raw exception messages) is logged only on the server and not returned to the client. The client should receive a generic, non-sensitive error message and, if needed, a generic error code that can be correlated with server logs.

For this specific view, the best minimal fix without changing existing functionality is to keep the logging line as-is (so developers still see the detailed error in logs) but change the HTTP response body in the broad except Exception as e: handler to a generic message that does not include e. That means editing backend/hoagiemail/api/stuff_posts_view.py at lines 46–48 to remove the f-string with {e} and replace it with a constant message like "Unexpected error retrieving posts.". No new imports or helper methods are required.