pynenc.trigger.log_messages¶
Stable log message vocabulary for the trigger system.
Centralizes the message names, entity-ref formatting, and participant
summaries that :class:pynenc.trigger.base_trigger.BaseTrigger emits during
event/condition/run lifecycle. Keeping the contract in one place lets the
Pynmon log-parser, renderer, docs, and tests share the same source of truth.
Message names use a trigger.<topic>.<verb> prefix so log filters can
slice the trigger lifecycle by topic without parsing message text.
Entity refs follow the kind:value convention already used by
pynenc.util.log and pynmon.util.log_parser. New kinds added here:
event:{event_id}trigger:{trigger_id}trigger-run:{trigger_run_id}condition:{condition_id}valid-condition:{valid_condition_id}source-invocation:{invocation_id}triggered-invocation:{invocation_id}atomic-service-run:{atomic_service_run_id}cron:{iso_timestamp}
List forms (events:[...] etc.) follow the same convention.
Module Contents¶
Classes¶
Stable lifecycle message names emitted by the trigger component. |
Functions¶
Format a single |
|
Format a list-form entity ref like |
|
Return the appropriate entity ref for the source of a condition context. |
|
Return extra |
|
Join non-empty tokens with single spaces. |
Data¶
API¶
- class pynenc.trigger.log_messages.TriggerLogMsg[source]¶
Stable lifecycle message names emitted by the trigger component.
- EVENT_EMITTED¶
‘trigger.event.emitted’
- CONDITION_MATCHED¶
‘trigger.condition.matched’
- CONDITION_REGISTERED¶
‘trigger.condition.registered’
- RUN_CLAIMED¶
‘trigger.run.claimed’
- RUN_SKIPPED¶
‘trigger.run.skipped’
- RUN_EXECUTED¶
‘trigger.run.executed’
- RUN_STORED¶
‘trigger.run.stored’
- CRON_CLAIMED¶
‘trigger.cron.claimed’
- CRON_SKIPPED¶
‘trigger.cron.skipped’
- pynenc.trigger.log_messages.TRIGGER_ENTITY_REF_KINDS: tuple[str, ...]¶
(‘event’, ‘trigger’, ‘trigger-run’, ‘condition’, ‘valid-condition’, ‘source-invocation’, ‘triggered-…
- pynenc.trigger.log_messages.TRIGGER_ENTITY_LIST_KINDS: tuple[str, ...]¶
(‘events’, ‘triggers’, ‘trigger-runs’, ‘conditions’, ‘valid-conditions’, ‘source-invocations’, ‘trig…
- pynenc.trigger.log_messages.ref(kind: str, value: str | None) str[source]¶
Format a single
kind:valueentity ref, returning ‘’ for empty values.- Parameters:
kind – Entity kind (e.g.
"event","trigger-run").value – Entity id; when falsy the helper returns the empty string so callers can drop the token from the message with a simple
filter.
- pynenc.trigger.log_messages.ref_list(kind_plural: str, values: list[str]) str[source]¶
Format a list-form entity ref like
events:[id1,id2].Returns ‘’ when
valuesis empty so callers can omit the token cleanly.
- pynenc.trigger.log_messages.context_source_ref(context: pynenc.trigger.conditions.ConditionContext) str[source]¶
Return the appropriate entity ref for the source of a condition context.
Maps each :class:
ConditionContextsubclass to the most informative ref:EventContext->event:{event_id}StatusContext/ResultContext/ExceptionContext->source-invocation:{invocation_id}CronContext->"cron:{iso_timestamp}"(no entity id; the timestamp is the only meaningful source identifier).
Returns the empty string when no source can be identified, so callers may join the result into a message without an extra branch.
- pynenc.trigger.log_messages.context_extra_tokens(context: pynenc.trigger.conditions.ConditionContext) list[str][source]¶
Return extra
key:valuetokens describing a context for log messages.These tokens travel alongside the source ref so the Log Explorer can show the matched status/exception/event-code without an extra backend hop. They intentionally use plain
key:valuetext rather than entity refs because they do not point at hydratable monitoring records.