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

Action status code catalog: name, description and severity for reported status codes

Aperta
#3,436 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
java, spring, sql
Ambito
api, backend, databases

Direzione di ricerca

Start by reading the action status and action entities, especially ActionStatus.code and Action.lastStatusCode, then trace feedback handling for DDI, DMF, cancel feedback, informational statuses, and auto-confirmation. Review the management REST API and its tests for action resources and filtering. Done means the catalog, automatic provisioning, exposed details, severity filtering, and the listed range and documentation fixes work together with existing integer fields preserved.

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

Descrizione

Motivation

Devices report numeric status codes in action feedback (DDI status.code, DMF code). hawkBit stores them (ActionStatus.code, Action.lastStatusCode) and you can filter on the number (GET /rest/v1/actions?q=lastStatusCode==1234). But a bare number tells an operator nothing. They can't see what 1234 means, whether it is a problem, or find all actions that ended with an error code.

This issue proposes a catalog of status codes with a name, description and severity, which clients can display and use for filtering.

Proposal

1. Status code entity

Field Type Notes
id long technical ID
code integer the reported code, unique
name string short label, e.g. DOWNLOAD_HASH_MISMATCH
description string longer text for display
severity enum INFO, WARNING, ERROR

Plus the usual audit fields. One flat table: a code means the same thing regardless of target type or software version. That keeps it simple. Per-type meanings could come later if needed.

2. Management REST API

  • GET /rest/v1/action-status-codes (paged, RSQL q on code, name, severity)
  • GET /rest/v1/action-status-codes/{id}
  • POST /rest/v1/action-status-codes
  • PUT /rest/v1/action-status-codes/{id}

No delete: statuses keep referencing codes, and a deleted code would be provisioned again on its next report. Access uses the existing permissions (no new permission set).

3. Auto-provisioning
When feedback (DDI, DMF or Mgmt confirmation) reports a code that isn't in the catalog, create an entry automatically with a default name (e.g. "Code 1234"), no description, and severity INFO. An operator can then fill in the details. Concurrent first reports of the same code must not fail the feedback (unique constraint plus get-or-create).

4. Exposing and filtering

  • MgmtActionStatus and MgmtAction expose the resolved code details (e.g. name and severity, or a link to the code resource), keeping the existing integer fields.
  • Filter actions by the severity of their last status code, e.g. GET /rest/v1/actions?q=lastStatusCode.severity==ERROR.
  • Ranges on the code: GET /rest/v1/actions?q=lastStatusCode=ge=200;lastStatusCode=le=299. The generic RSQL operators should already support this. Verify it, add a test, and document it.
Related fixes found while looking at this
  • docs/entity-definitions.md (and its MCP copy) shows lastActionStatusCode==200, but the RSQL key is lastStatusCode.
  • Action.lastStatusCode isn't updated for cancel feedback (addCancelActionStatus), informational statuses or auto-confirmation, so filtering on it misses those actions.
Backward compatibility

Additive only: the existing code/lastStatusCode integer fields, the DDI/DMF payloads and the lastStatusCode RSQL key stay unchanged.

Lingua principale
Java
Stelle
601
Fork
228
Merge medio
15h 58m
PR unite (30g)
62

Preparare l'ambiente

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-hawkbit/hawkbit

Tutte le issue di eclipse-hawkbit/hawkbit

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.