Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Output products could get "stuck" in an unexpected partially complete state when certain configured product paths are wrong

Open
  • Is something wrong?
#65 0 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
42/100
Issue type
Bug
Clarity
Needs clarification
Activity status
Stale
Tech stack
java
Domain
backend

Research direction

No files or tests are named in the issue. Start by tracing how configured output paths are validated and how output products and the run history file are committed, then reproduce the bad-path scenario. Done means a misconfigured path cannot leave products partially updated without either preventing the commit or recording the run state needed for rollback.

Written by the indexing model from the issue text.

Description

Because of the way MMTC's output products are written, it's possible for some products to be updated after a run when a bad/nonexistent path in the config (such as raw telemetry table) causes MMTC to abort before everything has been updated. This can result in a state where SCLK kernels and SCLKSCET files have been written but the run history file was never updated, meaning details of the run were never recorded and the run can't be rolled back. This is particularly confusing for users of the web UI as it appears that nothing was written in the "preview" view but upon refresh, the predicted correlation data become actual despite no evidence of new runs in the history widget.

Image note second correlation carat under the graph along with adjusted error graph, but no run IDs listed in the lower history widget (still erroneously says "initial state")

Instead, MMTC should probably be adjusted to handle this sort of misconfiguration in one of two ways:

  1. The bad path is checked and caught before we try to commit and either prevents a preview from being generated or grays out/disables the commit button (along with an error somewhere explaining why it can't commit)
  2. Completes and updates all the output products it can (most importantly run history file so i can roll back if the user wants to fix and try again) but throws an error/warning that it couldn't update the relevant product. Ostensibly this would require special handling in the run history file update to account for the nonexistent product that it wasn't able to update.

The first is likely an easier/safer solution as it doesn't have to account for cases where critical output products (such as SCLK kernels) can't be written vs. non-critical products (like the raw TLM table), but will involve upfront validation of all relevant output products and/or their output paths before anything is written.

Dominant language
Java
Stars
8
Forks
4
Avg merge
3d 22h
Merged PRs (30d)
1

Getting set up

  • Ships a Dockerfile or Docker Compose file
  • No pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from NASA-AMMOS/MMTC

All issues in NASA-AMMOS/MMTC

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.