Race condition can cache BFR=1.0 on large vessels (default reliability curve from OnAwake)

[GuyJustCool1]

Summary

On large vessels, TestFlight can cache a base failure rate (BFR) of 1.0 for engine parts, which results in effectively immediate failures (e.g. MTBF ~0.1–1s behavior).

Observed behavior

• Engines that should have normal reliability instead show very high failure rate and fail in quick cascade.
• Logs show entries like:
  • TestFlightCore([kspPartName = cryoengine-compsognathus-1:cryoengine-compsognathus-1]): BFR: 1.0000000
• Small/simple vessels may not reproduce; large/complex vessels do.

Expected behavior

• BFR should be calculated from the configured reliability curves, not from a default fallback curve.
• No permanent cache of BFR=1.0 unless the actual configured curve truly evaluates to that.

Suspected root cause

There appears to be an initialization-order race between OnAwake / OnStart and the manager polling path:

1. TestFlightInterop.OnAwake() triggers UpdatePartConfigs().
2. If TestFlightCore config list is not yet populated, alias/config resolution can be incomplete at that moment.
3. TestFlightReliabilityBase.OnAwake() creates a default reliability curve when reliabilityCurve == null:
   • reliabilityCurve.Add(0f, 1f).
4. On large vessels, manager update/polling can call GetBaseFailureRate() before SetActiveConfig() loads real config curves.
5. Result: default curve evaluates to 1.0, gets cached as base failure rate, and is not recalculated later.

Relevant code areas

• TestFlightReliabilityBase.OnAwake() default curve initialization.
• TestFlightCore.UpdatePartConfig() / alias propagation.
• Manager path that reads base failure rate during vessel/UI status update.
• Base-failure caching logic in GetBaseFailureRate().

Reproduction notes

• Repro seen with KSP 1.12.5 on large staged craft (high part count).
• Symptom disappears when using a config-side workaround that ensures reliability curve is loaded at module level before fallback can occur.

Workaround tested locally

In a config template, placing the reliability curve at MODULE level (not only nested in CONFIG) prevented the dangerous default (0,1) fallback from being used before config activation.

Suggested fixes

Potential options (any one or combination):

1. Avoid reliabilityCurve.Add(0f,1f) as default in OnAwake (use safer minimum default or defer).
2. Ensure base failure rate is not cached until active config is fully resolved.
3. Invalidate/recompute cached BFR after successful SetActiveConfig().
4. Gate manager polling until core/module configuration is finalized.

Happy to provide logs and a minimal repro craft if helpful.

[siimav]

Well, if you can reliably replicate the issue then tell your clanker to add logging into those suspicious code paths and prove the theory.