alarm: clarify queryAlarms entity / layer semantics (doc only)#158
Closed
wu-sheng wants to merge 1 commit into
Closed
alarm: clarify queryAlarms entity / layer semantics (doc only)#158wu-sheng wants to merge 1 commit into
wu-sheng wants to merge 1 commit into
Conversation
Updates the AlarmQueryCondition input type doc to match how the OAP
backend actually filters:
* Relation entities (ServiceRelation, ServiceInstanceRelation, etc.)
do EXACT match on (id0=src AND id1=dest). The previous doc said
the entity 'matches whether it appears as the source or the dest',
which would imply id0 OR id1 — actual behaviour is the strict AND.
Operators wanting 'anything involving service A' should pass a
non-relation Entity {Service A} (which expands to id0=A OR id1=A).
* Layer matching is single-value-per-row. An alarm record stores ONE
layer (the alphabetically first when the alarmed service has multiple
layers). The previous doc implied multi-value matching ('matches when
any one is in the list'), but the persisted value is a scalar.
Doc-only change; no schema breakage.
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
1 participant
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.
Summary
Doc-only fix to
alarm.graphqlsso the schema text matches how the OAP backend actually filtersqueryAlarms.What was inaccurate
{ServiceRelation, A→B}) matches alarms 'whether the entity appears as the source or the dest of the relation' — implyingid0 OR id1. The actual OAP backend uses strict AND (id0=src AND id1=dest), which makes the relation filter narrow to one specific edge. Operators who want 'any alarm involving service A' should pass the non-relation{Service A}entity (which expands toid0=A OR id1=A).[GENERAL, K8S_SERVICE]is filed underGENERALand onlylayers: [\"GENERAL\"]matches it.Why doc-only
Both issues are cosmetic — the GraphQL types, names, and arguments are unchanged. The fix replaces the misleading prose so:
The narrowing for relations is a deliberate OAP design choice (per-entity AND/OR semantics in the storage DAO) and shouldn't be changed without breaking the relation-filter contract.
No schema breakage
queryAlarmsat all) unaffected.Test plan
🤖 Generated with Claude Code