fix: harden cloud run runtime guard#200
Conversation
Co-Authored-By: Codex <noreply@openai.com>
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: eb1314d42f
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| f'AND resource.labels.service_name="{service}" ' | ||
| f'AND timestamp >= "{service_since_text}"' | ||
| ) | ||
| log_filter = _cloud_run_log_filter(service, service_since_text, _region_for_service(service)) |
There was a problem hiding this comment.
When CLOUD_RUN_SERVICE_TARGETS_JSON contains a disabled target for the same service before an enabled target (or before a service also supplied via RUNTIME_GUARD_CLOUD_RUN_SERVICES), _load_services() ignores that disabled target but _region_for_service() still returns its region. Because this new call now applies that region to the Cloud Run log filter, the guard can query the disabled target's location and miss failures/successes from the actual deployed region.
Useful? React with 👍 / 👎.
| _status(entry) == 429 | ||
| and _request_path(entry) == "/monitor-dispatch" | ||
| and "NO AVAILABLE INSTANCE" in _entry_text(entry).upper() |
There was a problem hiding this comment.
When RUNTIME_GUARD_SCHEDULER_JOB_PATTERN is broad enough to include the monitor dispatcher job, Cloud Scheduler target failures are logged as URL_ERROR/URL_UNREACHABLE entries (Google docs: https://docs.cloud.google.com/scheduler/docs/troubleshooting#job-fails-due-to-unreachable-destination-target), so they can lack httpRequest.status/requestUrl; this predicate won't match those 429 monitor-dispatch capacity entries, and _is_failure will still alert on the scheduler failure that the new ignore was supposed to suppress.
Useful? React with 👍 / 👎.
1 participant
Summary
Test Plan