Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#338 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
52/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
rust
Área
tooling

Línea de trabajo

Empieza siguiendo ParticipantType::Actor desde plantuml/parser/puml_parser/src/sequence_diagram/ a través de validation/core/src/models/sequence_diagram_models.rs hasta component_sequence_validator.rs. Compara el ejemplo documentado de actor en bazel/rules/rules_score/docs/user_guide/architectural_design.md con las comprobaciones de nombres e interfaces. Se considera terminado cuando los participantes actor sigan siendo distinguibles y queden excluidos de las comprobaciones de consistencia pertinentes, sin debilitar las comprobaciones para los participantes validados.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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)
Lenguaje dominante
Rust
Estrellas
8
Forks
38
Merge medio
1 d 2 h
PR fusionados (30 d)
33

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

  • Sin Dockerfile ni archivo de Docker Compose
  • Sin plantilla de pull request
  • Sin guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de eclipse-score/tooling

Todos los issues de eclipse-score/tooling

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.