hotfix: guard fADC pulse fitting against channels missing from /daq/fadc CCDB config

[mathieuouillon]

Summary

DetectorEventDecoder.fitPulses can throw NullPointerException on every decoded event when a channel is present in the translation table (/daq/tt/<det>) but has no matching row in the FADC config table (/daq/fadc/<det>). This is a regression introduced by #1323, which removed the hasEntryByHash guard that previously protected the nsa/nsb/tet/pedestal lookups. This PR restores that guard.

Regression

Before #1323, the fitter looped over fitterTables and only read parameters when the entry existed:

else if (daq.hasEntryByHash(hash) == true) {
    int nsa = daq.getIntValueByHash("nsa", hash);
    int nsb = daq.getIntValueByHash("nsb", hash);
    int tet = daq.getIntValueByHash("tet", hash);
    // ... fit ...
}

#1323 refactored this into a direct getOrDefault lookup + a dedicated fitPulses(data, cfg) helper, but the per-hash existence check was dropped, so getIntValueByHash is now always called. IndexedTable.getIntValueByHash does not null-check its map lookup:

public int getIntValueByHash(String item, long hash) {
    return entries.getItemByHash(hash).getValue(entryMap.get(item)).intValue(); // null -> NPE
}

So a hit whose (crate,slot,channel) is absent from the FADC table unboxes a null Integer and throws.

Symptom

java.lang.NullPointerException: Cannot invoke "java.lang.Integer.intValue()" because the return value of "java.util.Map.get(Object)" is null
    at org.jlab.utils.groups.IndexedTable.getIntValueByHash(IndexedTable.java:179)
    at org.jlab.detector.decode.DetectorEventDecoder.fitPulses(DetectorEventDecoder.java:210)
    at org.jlab.detector.decode.DetectorEventDecoder.fitPulses(DetectorEventDecoder.java:255)
    at org.jlab.detector.decode.CLASDecoder.initEvent(CLASDecoder.java:750)

Because decoding is the first stage of reconstruction, this aborts the whole cook. In the RG-L p0v11 production it failed 618/623 reconstruction jobs; each affected job logged the exception on ~every event, growing multi-MB logs (~16 GB for the workflow) and secondarily exhausting the farm output quota.

Root cause (real-world trigger)

RG-L data contains an LTCC ADC hit on hardware (crate 19, slot 18, channel 150). The translation table maps it, but the FADC config table has no such row:

# /daq/tt/ltcc   (crate 19 = sector 4)
19  18  150  4  1  4  0      # sector 4, layer 1, component 4  (all other sectors: channel 15)

# /daq/fadc/ltcc  (crate 19, slot 18)
19  18  {12, 13, 14, 115}    # no 150

This particular inconsistency is a data/CCDB issue that will be addressed separately by the DAQ table maintainers, but the decoder should not hard-fail on it — a channel with no fit configuration should be skipped, exactly as it was before #1323.

The fix

     private void fitPulses(DetectorDataDgtz data, IndexedTable cfg) {
         final DetectorDescriptor dd = data.getDescriptor();
         final long hash = IndexedTable.DEFAULT_GENERATOR.hashCode(dd.getCrate(), dd.getSlot(), dd.getChannel());
+        // Guard re-added (was removed in PR #1323): skip channels with no FADC config entry,
+        // otherwise getIntValueByHash returns null and NPEs (e.g. LTCC crate 19 / slot 18 / chan 150).
+        if (!cfg.hasEntryByHash(hash)) return;
         final int nsa = cfg.getIntValueByHash("nsa", hash);
         final int nsb = cfg.getIntValueByHash("nsb", hash);
         final int tet = cfg.getIntValueByHash("tet", hash);

One line + comment; behavior matches 14.1.1 (skip the channel).

Validation

Decoded 2000 events of RG-L run 23061 (clas_023061.evio.00040), variation rgl_spring2025, timestamp 07/20/2026-16:00:00:

<COATJAVA>/bin/decoder -n 2000 -c 2 -x 07/20/2026-16:00:00 -V rgl_spring2025 \
    -o out.hipo /cache/clas12/rg-l/data/clas_023061/clas_023061.evio.00040

build	NullPointerException / 2000	decode	output
14.1.2 (released binary)	1999	NPE on ~every event	invalid
this branch, unpatched (same tree)	1999	NPE on ~every event	invalid
this branch, patched	0	clean, exits 0	valid HIPO

The unpatched-vs-patched pair is the same build tree with only this one-line change differing, isolating the fix as the sole cause. The patched decoder simply skips the unconfigured LTCC channel and processes everything else normally.

Impact / risk

• Restores pre-feat: replace loop with map lookup #1323 behavior; no change for any channel that does have a /daq/fadc entry.
• Prevents a single missing/mismatched CCDB row from aborting an entire decode.

Alternative considered

Making IndexedTable.getIntValueByHash null-safe would harden all callers, but is a broader behavioral change; restoring the local guard is the minimal, targeted fix and matches the long-standing prior behavior. Happy to also add a null-check / warning in IndexedTable if preferred.