Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

component_sequence naming-consistency check ignores 'actor' participant type, contradicting own docs example

Aperta
  • Qualcosa non va?
#338 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
52/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
rust
Ambito
tooling

Direzione di ricerca

Inizia seguendo ParticipantType::Actor da plantuml/parser/puml_parser/src/sequence_diagram/ passando per validation/core/src/models/sequence_diagram_models.rs fino a component_sequence_validator.rs. Confronta l'esempio documentato di actor in bazel/rules/rules_score/docs/user_guide/architectural_design.md con i controlli sui nomi e sulle interfacce. Il lavoro è completo quando i partecipanti actor rimangono distinguibili e sono esclusi dai controlli di coerenza pertinenti, senza indebolire i controlli per i partecipanti convalidati.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Summary

component_sequence_validator's naming-consistency check (check_participant_aliases) enforces exact SET equality between <<unit>> aliases in component diagrams and all participant aliases used in sequence diagrams. This appears to discard the PlantUML actor participant type, even though the parser tracks it, and even the tool's own documentation example looks like it would fail this check.

Observed behavior

In validation/core/src/models/sequence_diagram_models.rs, SequenceDiagramIndex::from_diagrams builds used_participants purely from interaction.caller/interaction.callee (and ret.caller/ret.callee), with no distinction based on participant kind (participant vs actor vs boundary, etc.):

if !interaction.caller.is_empty() {
    used_participants.insert(interaction.caller.clone());
}
if !interaction.callee.is_empty() {
    used_participants.insert(interaction.callee.clone());
}

component_sequence_validator.rs::check_participant_aliases then requires this set to equal exactly the set of <<unit>> aliases from the component diagrams (bidirectional check: "Missing sequence participant" and "Unexpected sequence participant").

Meanwhile, the PlantUML sequence-diagram parser (plantuml/parser/puml_parser/src/sequence_diagram/src/syntax_parser.rs) does parse actor as a distinct ParticipantType::Actor ("actor" => Some(ParticipantType::Actor)), and the component-diagram parser has an equivalent ComponentType::Actor. This information appears to be dropped before it reaches the FlatBuffers model consumed by SequenceDiagramIndex.

Expected behavior

architectural_design.md itself documents the following canonical dynamic-view example:

@startuml MySeooc_WriteSequence

actor Caller
participant KeyValueStore
participant StorageBackend

Caller -> KeyValueStore : write(key, value)
KeyValueStore -> StorageBackend : flush()
StorageBackend --> KeyValueStore : OK
KeyValueStore --> Caller : Result::Ok

@enduml

Here Caller is declared with the actor keyword and is not a <<unit>> in the paired static diagram (only KeyValueStore and StorageBackend are). Based on the validator code, Caller would be collected into used_participants (it appears as caller/callee of two interactions) and then fail "sequence participant not found in component unit aliases," since no <<unit>> alias named Caller exists.

Expected: actor-typed sequence participants represent entities outside the validated architectural boundary (external callers, consumers, generated/out-of-tree code, etc.) and should be excluded from the naming-consistency SET-equality check — consistent with standard UML "actor" semantics and with the tool's own documented example.

Why this looks like a tooling bug, not a deliberate design choice

  • The parser already distinguishes actor from participant/boundary/etc. at the syntax level for both sequence and component diagrams.
  • The static-side validator (bazel_component_validator) does filter by stereotype (<<unit>>/<<component>>/<<SEooC>>), ignoring plain/unstereotyped elements — the dynamic-side validator has no equivalent filter, seemingly because participant-kind information is lost between parsing and the FlatBuffers model consumed here.
  • The docs' own reference example (architectural_design.md, Dynamic Architecture section) would not pass validation as written, based on this code path.

Impact

There's currently no supported way to document an interaction with an out-of-boundary actor (e.g. an external caller, or code generated outside the dependable element's own Bazel package) in a sequence diagram without either:

  • inventing a fictional Bazel unit() purely to satisfy the validator, or
  • omitting the actor from the sequence entirely and only referencing it in prose/notes.

Suggested fix

Preserve ParticipantType/ComponentType (or at least an is_actor flag) through to the FlatBuffers model, and exclude actor-typed participants from the naming-consistency and interface-consistency checks in component_sequence_validator.rs. This would align enforced behavior with the tool's own documented example and with standard UML actor semantics.

Suspected area

  • plantuml/parser/puml_parser/src/sequence_diagram/ (parser retains ParticipantType::Actor, downstream FlatBuffers model may not)
  • validation/core/src/models/sequence_diagram_models.rs (used_participants collection, no kind filter)
  • validation/core/src/validators/component_sequence_validator.rs (check_participant_aliases)
  • bazel/rules/rules_score/docs/user_guide/architectural_design.md (documented example that appears inconsistent with current validator behavior)
Lingua principale
Rust
Stelle
8
Fork
37
Merge medio
1g 9h
PR unite (30g)
22

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

  • Nessun Dockerfile né file Docker Compose
  • Nessun modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di eclipse-score/tooling

Tutte le issue di eclipse-score/tooling

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.