Show effective rate limits in tooltip on account page - #2524
Merged
Merged
Conversation
Documentation build overview
52 files changed ·
|
Flix6x
added a commit
that referenced
this pull request
Sep 16, 2026
The guard raised from inside the writing loop, so a scheduler returning a permitted sensor before an unchecked one would have written the first. The job's transaction would have rolled that back, `save_to_db` only flushing, but a refusal should not rest on the caller's transaction discipline, and `make_schedule` is called directly too. Every sensor the scheduler returned is now judged before any of them is written, and the message names them all. A `SQLAlchemyError` now rolls the session back before it is reported as unknown sensors: the session is unusable until it is, and the caller goes on to render a response through it. The changelog entry also read "PR #2524" while linking to this one. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Signed-off-by: F.N. Claessen <claessen@seita.nl>
Flix6x
added a commit
that referenced
this pull request
Sep 16, 2026
…2536) * Hold an automation's schedule to the sensors it was checked against An automation's output sensors are checked against its creator's permissions when the automation is created, which is the only moment a user is present. They are predicted from the fields that name them, and a sensor the prediction misses is not left unchecked so much as checked for the wrong thing: it is read as an input, so read access is asked for where recording data calls for create-children access. A schedule job created by an automation is now held to that prediction, and refuses to record on any other sensor. Where there is nothing to hold the job to, it proceeds as before: a job that is not an automation's, an automation deleted since the job was queued, or one whose sensors cannot be determined, which is logged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WS6V8nZyRzMxsvqGnNpUTk Signed-off-by: F.N. Claessen <claessen@seita.nl> * changelog: point at the PR number Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WS6V8nZyRzMxsvqGnNpUTk Signed-off-by: F.N. Claessen <claessen@seita.nl> * Give the scheduler its flex config as written, and hold the guard to it `resolve_schedule_automation_sensors` handed the scheduler a flex config that had already been through `AssetTriggerSchema`, so `collect_flex_config` — which merges the asset tree's config with the message's, reading sensors by id — met `Sensor` objects where it expects ids and raised a `ProgrammingError` no caller catches. A data generator deserializes its own config, so the scheduler now receives the config as it was written and does that itself. The trigger message is loaded for its timing and its asset only. A database error joins what is reported as unknown sensors, that being what it means here. With resolution reliable, the guard fails closed: an automation whose sensors cannot be determined records nothing, rather than proceeding unchecked. The refusal test no longer stubs the permitted set, so it derives it the way production does. Closes the blocker recorded on #2421. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WS6V8nZyRzMxsvqGnNpUTk Signed-off-by: F.N. Claessen <claessen@seita.nl> * Address Copilot: refuse the whole set before writing any of it The guard raised from inside the writing loop, so a scheduler returning a permitted sensor before an unchecked one would have written the first. The job's transaction would have rolled that back, `save_to_db` only flushing, but a refusal should not rest on the caller's transaction discipline, and `make_schedule` is called directly too. Every sensor the scheduler returned is now judged before any of them is written, and the message names them all. A `SQLAlchemyError` now rolls the session back before it is reported as unknown sensors: the session is unusable until it is, and the caller goes on to render a response through it. The changelog entry also read "PR #2524" while linking to this one. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Signed-off-by: F.N. Claessen <claessen@seita.nl> * docs/changelog: name the pull request the v0.24.0 entry links to "Allow using numeric values for flex-model fields accepting dimensionless quantities" read "PR #1144" while linking to pull/1299. The link is the right one: #1299 is "Allow numeric values for dimensionless fields", where #1144 is multi-commitments. Found while fixing the same defect in this PR's own entry. It is the only other one: all three changelogs are now free of link texts that disagree with what they link to. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Signed-off-by: F.N. Claessen <claessen@seita.nl> * Address review: changelog placement and line breaks Automations are unreleased, so the guard is not a fix to anything users have run into. Move its entry from Bugfixes to the per-PR automations section, and word it as a property of the feature rather than as a behaviour that changed. Break the three new comment blocks after punctuation. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Signed-off-by: F.N. Claessen <claessen@seita.nl> * Say which exceptions the sensor resolver wraps The docstring claimed anything raised while working out the config is reported as AutomationSensorsUnknown, where only NotImplementedError, ValueError and SQLAlchemyError are wrapped and the rest propagates. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Signed-off-by: F.N. Claessen <claessen@seita.nl> --------- Signed-off-by: F.N. Claessen <claessen@seita.nl> Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
5 tasks
Signed-off-by: Nicolas Höning <nicolas@seita.nl>
…a PR ID that was wrong (2444 -> 2464) Signed-off-by: Nicolas Höning <nicolas@seita.nl>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Description
Users might be interested not only what their plan is called, but what limits are entailed (also for the default plan).
This PR adds a tooltip for this.
documentation/changelog.rstLook & Feel
Got to an account page and hover over the plan name.