Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

OCSF shorthand renders Unknown and Other severities as [INFO]

Ouverte Adaptée aux débutants
  • Quelque chose ne va pas ?
#3,886 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
2/5
Temps estimé
1-3 heures
Accessibilité débutants
72/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
rust
Domaine
observability

Piste de recherche

Commencez dans crates/openshell-ocsf/src/format/shorthand.rs, au niveau de severity_tag, et comparez-le à severity_char ainsi qu'aux tests qui s'y trouvent. Lisez crates/openshell-ocsf/src/enums/severity.rs, puis exécutez cargo test -p openshell-ocsf. Le travail est terminé lorsque l'intégralité du mappage de 0..=6 et 99 est couverte, avec Unknown et Other distincts de Informational et cohérents avec les fonctions utilitaires sœurs.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

state:triage-needed

OCSF shorthand renders Unknown and Other severities as [INFO]

User Story

As someone reading sandbox OCSF audit logs in openshell.log or a gRPC log push, I want the severity tag on each line to reflect the event's actual severity, so that an event of unclassified severity is distinguishable from one deliberately marked informational.

Problem Statement

severity_tag in crates/openshell-ocsf/src/format/shorthand.rs maps only 2..=6 explicitly and sends every other value to a _ => "[INFO]" arm:

pub fn severity_tag(severity_id: u8) -> &'static str {
    match severity_id {
        2 => "[LOW]",
        3 => "[MED]",
        4 => "[HIGH]",
        5 => "[CRIT]",
        6 => "[FATAL]",
        _ => "[INFO]",
    }
}

SeverityId has two members outside 2..=6 that are real, serializable values: Unknown = 0 and Other = 99 (crates/openshell-ocsf/src/enums/severity.rs). Both land in the _ arm, so they render as [INFO] — the same tag as SeverityId::Informational = 1, which is the default severity for most builders (api_activity, base, config, http, lifecycle, network, process, ssh all default to SeverityId::Informational).

The two sibling helpers in the same module already disagree with this. severity_char (line 27) maps both 0 and 99 to ' ', and its test test_severity_char_mapping asserts exactly that. SeverityId::shorthand_char in the enum also returns ' ' for both. severity_tag is the one that is actually used for rendering (format_shorthand, line 202), and it is the one that is wrong.

Impact / Why This Matters

[INFO] is the most common tag in the log, so folding two distinct severities into it makes an unclassified event indistinguishable from an informational one. For an audit trail this means a line that reads as routine cannot be triaged by severity alone; an operator filtering for non-informational events would not surface it. The full OCSF JSON is still correct — severity_id serializes as 0 or 99 — so this is a display-projection bug, not a data bug, but openshell.log is what most operators read.

There is no workaround today. The only way to recover the real severity is to read the JSONL file rather than the shorthand log.

Acceptance Criteria
  • severity_tag(0) and severity_tag(99) do not return "[INFO]".
  • severity_tag(0) and severity_tag(99) are identical to each other and distinct from severity_tag(1).
  • severity_tag is consistent with severity_char and SeverityId::shorthand_char for the same input.
  • A unit test covers the full 0..=6 plus 99 mapping, not just the 0..=6 range that was already handled.
  • severity_tag(1) through severity_tag(6) are unchanged, so existing log consumers are unaffected.
Reproduction Steps
  1. Build any event whose severity_id is 0 or 99 through the OCSF builders, or call severity_tag directly.
  2. Format it with OcsfEvent::format_shorthand.
  3. Observe the severity tag in the output.
severity_tag(0)  == "[INFO]"   // expected: distinct from Informational
severity_tag(99) == "[INFO]"   // expected: distinct from Informational
severity_tag(1)  == "[INFO]"   // Informational
severity_char(0) == ' '        // Unknown — the two helpers disagree
severity_char(99) == ' '       // Other  — the two helpers disagree
Environment
  • OpenShell: main at commit cf1bbb965
  • OS: Windows 11
  • Toolchain: 1.98.0-x86_64-pc-windows-gnu (the pinned 1.95.0 MSVC toolchain needs link.exe, which is not installed on this machine, so I built with the GNU toolchain for the same x86_64-pc-windows target)
  • No mise run available in this environment, so verification was cargo test -p openshell-ocsf and cargo clippy -p openshell-ocsf --all-targets -- -D warnings rather than mise run pre-commit
Logs

Not applicable — this is a formatting defect, reproducible with a direct unit assertion as shown above.

Notes

I have a branch and a candidate fix ready at aniruddhaadak80:fix/ocsf-severity-tag-unknown (one-line change plus a test), but I am not opening a PR yet because the vouch-check workflow will auto-close it. I would rather ask first.

I picked [UNKN] to match the existing 5-character tags ([INFO], [LOW], [MED], [HIGH]), which keeps the log column alignment. A maintainer may prefer a different spelling, or may prefer severity_tag to derive from SeverityId::shorthand_char / label() so the three helpers cannot drift apart again — I think that is the more durable fix, but it is a larger diff and I did not want to make that call unilaterally.

Langage dominant
Rust
Étoiles
8.7k
Forks
1.3k
Merge moyen
1 j 22 h
PR mergées (30 j)
328

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de NVIDIA/OpenShell

Toutes les issues de NVIDIA/OpenShell

Issues similaires

Plus d'issues Rust

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.