Deprecations and Breaking Changes

Behaviour changes that can alter numbers#

These are corrections. The new behaviour is right, and it may still be visible in a report.

Retired event periods always close#

An event period that was retired could remain open-ended, leaving its duration growing indefinitely. Every duration-derived measure above such an event was wrong, usually by a growing amount.

Retirement now always closes the period.

What to check. Duration, availability, and utilisation measures on event schemes where events are retired. Where the problem existed, values will step to the correct figure — which looks like a change when it is a correction.

Ordinal attribute lookups are case-sensitive#

String comparison on attribute values in ordinal lookups is now case-sensitive.

What to check. If any ordinal attribute lookup relied on case-insensitive matching — Line A matching line a — it will no longer match. Review the attribute values against the lookup values and align their case.

This is the change on this page most likely to break something quietly, because a failed lookup produces an absent value rather than an error.

MQTT consumer placeholders are case-insensitive#

The opposite direction: the MQTT consumer's model attribute placeholder replacement was case-sensitive and is now case-insensitive.

What to check. Placeholders that previously failed to resolve will now resolve, so topics that were being published to an unresolved path will move. Confirm the resulting topics are the ones your subscribers expect before assuming this is purely a fix.

Template updates preserve user-added calculations#

On a locked-retrieval template update, calculations a user had added to an instance were previously removed. They are now preserved.

What to check. Nothing is lost by this. It does mean a model that had been quietly losing user calculations on every template update will stop, so instances may retain more than the person running the update expects.

Beginning of time as a first calculation datetime#

"Beginning of time" is now available as the first calculation datetime. This is additive — existing configurations are unaffected — but it changes what a newly configured calculation can be set to.

Measure integration sends attribute-only changes it used to skip#

An attribute edited on an event period that had already ended was stamped with the period end, so it fell below the integration's watermark and was never pushed. It is now detected and sent.

Two things follow. Consumers start receiving changes they were never previously sent — if anything downstream assumed those never arrived, it will now see them. And the upgrade clamps integration watermarks that the old behaviour had advanced into the future, so an integration that had gone quiet starts catching up on its first scan after the upgrade. Expect a burst of traffic, then a return to normal.

Integration placeholder timestamps shift to the instance time zone#

[periodstart] and [periodend] in a measure integration resolved against the server's operating system time zone rather than the instance time zone. Where those differ, payload timestamps will change — to the correct values.

This is the change most likely to look like a regression downstream. If a receiving system, report or ETL step had been compensating for the old offset, that compensation must be removed at the same time as the upgrade.

Stranded tag transform configuration is deleted during the upgrade#

Where a tag's retrieval type had been changed from Aggregated to Calculated, hidden TagTransform rows were left behind. The upgrade removes them, clears template links that pointed at them, and writes a System Migration audit row for each. Inspect the Log table afterwards to see exactly what was removed.

Template updates leave an instance's Time Slice Aggregation alone unless the template locks it#

A template update previously pushed the template's Time Slice Aggregation type onto every instance regardless of locks. It now does so only when the new lock beside Event Scheme Aggregation on the measure form's Time Slice Aggregation tab is set on the template. Existing templates have the lock unset.

What to check. If you relied on a template update to correct an instance's aggregation type, set the lock on the template measure and run the update again. If you had been re-applying a per-instance Average after every update, you no longer need to — and the next update will not undo it.

Template updates no longer bump the version of unchanged measures with limits#

A measure carrying limits took Version+1 on every template update whether or not anything changed, so its instances and derived templates showed "update required" straight afterwards. The version now moves only when the limit reconciliation changes something.

What to check. Nothing breaks. On a template-server estate, expect the "update required" indicators to settle after the first update on this build.

Replicated weekly periods match on start time as well as week and year#

A replicated weekly measure posting into a calendar whose year does not start in January could match two weeks a year apart that share the same week and year label, and fail. The match now also requires the local period start to be within 14 days of the posted one. Stored labels and the engine are unchanged, so a site and the centre can be upgraded in either order.

Refresh triggers carry their own data source#

Refresh triggers on measure calendars and event triggers are linked directly to a data source rather than through the measure's or trigger's retrieval connection. The upgrade script carries existing links across. What to check. After the upgrade, a refresh trigger node shows the data source it is linked to; a retrieved measure or event trigger that could not previously take a refresh trigger (one sourced from a calculated tag, for instance) now can.

Skip To closes open event periods#

Skip To on an event scheme (the form, or --gap-skip-to) closes every open preferred period that started before the scheme's current position, at that position, with the engine's forced-close quality, before moving the position forward. This is additive — nothing happens unless you issue the command — but it is not undoable, so read Event Lifecycle Operations before using it on a production scheme.

CLI changes that affect scripts#

If you have scripts driving the Infohub CLI, read this section.

The batch wrappers now return the real exit code#

infohub-config.bat and ihc.bat ended with a cosmetic echo.. A batch file exits with the code of its last command, so the wrapper returned 0 for every failed command, whatever the CLI itself had returned.

What to check. Any script that called the wrapper and branched on the exit code was taking the success path unconditionally. Those scripts may now start failing — correctly, on errors that were always happening. Review anything that has "always worked" through the wrapper before assuming the new failures are new problems.

Entity type names are matched case-insensitively#

--destination-entity-type metricfolder was rejected while MetricFolder was accepted, and the error listed the valid types in canonical casing without saying that the casing was the objection. Both are now accepted. This is purely permissive — no existing invocation breaks.

--create failure now exits 10#

Previously, --create could log a genuine failure — unreachable host, bad credentials, an assembly that would not load — and then print a success line and exit 0.

Because the schema is laid down as a base version and then upgraded, a failure part-way leaves a partially created database. Any script trusting the exit code carried on and built a model against it.

Failure is now exit 10.

What to check. A script that worked by accident because it never saw a failure will now stop where it should. That is the intended outcome. Confirm your scripts handle a non-zero exit code rather than assuming success.

Success lines are gated on the exit code#

--import no longer prints "imported successfully" underneath the error explaining the failure. Output and exit code now agree.

What to check. Any script parsing stdout for a success string. Read the exit code instead.

Template-ness follows the parent on every create path#

Creating a measure under a template parent now produces a template measure and bumps the parent's version, even when --view-type is omitted. This applies to --create-measure, --create-tag-transform including its --parent-id-only form, and both --bulk-create-aggregation and --bulk-create-retrieved.

Previously a bulk create inside a template minted every row as an ordinary model measure — invisible to instantiation, with no version bump.

What to check. Templates built by script on an earlier build may be incomplete: measures that should be template measures may be model measures. Verify with --list-measures, which reads with the same rule.

DisplayOrder appends#

Created measures take max(sibling) + 1 rather than 0.

What to check. Scripts that relied on new measures sorting first. The new behaviour means a model reads in the order it was built, which is almost always preferable.

A bad invocation no longer launches the interface#

An unhandled or malformed invocation previously launched the Flow Config window. It now exits 1.

What to check. Any automation that tolerated a typo by having a window open and be closed. This was never intended behaviour, and on an unattended server it left a window open indefinitely.

Tab completion candidates changed#

--complete now derives candidates from the parser's own option set. It previously offered names the parser rejects and hid names that work.

What to check. Nothing functional; completions are now correct.

--list-connection-types no longer loads package blobs#

A performance fix, taking the verb from minutes to seconds on instances with large plugin packages.

What to check. If a script relied on the side effect of packages being loaded, it no longer happens.

--attach-measure-consumer needs a calendar or event scheme on a multi-scheme measure#

The verb now stamps the default Integration Engine and the measure's calendar or event scheme, as a drag in the interface does. On a measure with several calendars or event schemes you must pass --time-scheme-id or --event-scheme-id; the verb refuses rather than guessing. It also refuses on an instance with no Integration Engine, and refuses a consumer that cannot push raw values when the measure is a tag (timestamp measure) — ordinary measures accept every consumer.

What to check. Scripts that attach consumers to measures with more than one calendar now need the extra option. Bindings written by an earlier 7.2.0 build carry no engine and no calendar and were never sent; re-attach them on this build.

--attach-measure-event-scheme writes event scheme sets and clears time slices#

The verb now writes the event scheme sets the interface writes, refuses a foreign event scheme on a measure that aggregates an event, and deletes the measure's time slices after a successful attach so the engine rebuilds them. Re-attaching an already-linked event scheme repairs its sets instead of adding a duplicate row.

What to check. A script that attached an event scheme on an earlier 7.2.0 build left the measure without sets, and the engine failed on every scan; re-run the attach on this build to repair it. Expect the time slices to be rebuilt on the next scan.

--delete-entity cascades#

The verb deletes the way the interface does: folders to any depth, their metrics and event schemes, and every measure beneath, in one transaction. It previously stopped on the first dependent row and deleted nothing.

What to check. A script that relied on --delete-entity refusing a non-empty folder as a safety net no longer has one. Use --dry-run first.

--update-all-out-of-sync covers more than folders#

The verb scanned templated folders only unless --include-children was given. It now scans template-linked folders, metrics, event schemes and measures.

What to check. A scheduled run will update entities it previously skipped. That is the intended behaviour; review the first run's output.

--cleanup-delinked --property-type timescheme removes limits#

Removing a delinked calendar from a measure now also removes the measure's limits on that calendar, as the interface does, and refuses while a consumer, tag transform, sourced limit or message segment still uses the calendar.

--register-with-bootstrap fails on a refused registration#

The verb previously printed success and exited 0 when Flow Bootstrap refused the registration. It now reports the refusal with Bootstrap's reason and exits non-zero.

What to check. Pipelines that registered an instance and carried on may now stop at this step — on a refusal that was always happening.

Verbs not available in Flow 7.2.0#

Several options exist in the parser but are gated out of this release. Each reports a specific "not available in Flow 7.2.0" message and exits 1, so a gated verb is distinguishable from a typo:

• --health
• --eventlog
• --view-definition, --import-definition, --propagate-definition
• --execute-filter
• --create-model-attribute-folder

--create-function-folder is also gated, per the parity rulings applied in this release.

--gap-skip-to was gated in earlier 7.2.0 builds and is implemented in the release: with --entity-type eventscheme, --entity-id and --gap-skip-to-date it moves an event scheme's processing position forward past a data gap. It refuses a template scheme, a date at or before the scheme's current position, and a date in the future.

What to check. A script using any of the gated verbs will now fail with a clear message rather than a generic error. Remove or guard those calls. A script that guarded --gap-skip-to as unavailable can drop the guard.

Chart operations not available from the CLI#

Charts can be created, configured, and released or un-released as templates from the CLI. The following remain Flow Config activities:

• Chart delete and chart export
• Chart template link, delink, instantiate, and synchronise

What to check. A build script cannot fully manage chart template instances. Plan around the boundary — create and release from the CLI, instantiate and update in Flow Config. See Authoring Charts from the CLI.

Configuration behaviour worth knowing#

Not breaking changes, but behaviour that may differ from expectation:

Message channels default to Retrieved and refuse System.

Consumer attaches are undeployed by default. --attach-measure-consumer attaches without deploying; pass --active to deploy. This matches the interface.

Only consumers that can push raw values can be attached to a tag, in the interface as well as the CLI. The Integration panel previously accepted any consumer on a timestamp measure and produced a binding that could not be deployed.

Entities are created licensed.

Timestamp measures cannot be individually deployed or undeployed.

Raw chart adds validate against the factory, and refuse custom types by design. A --force option exists where a raw add is genuinely intended.

--create-template refuses model-side destinations.

Database script repairs#

The 7.2.0 update script performs data repairs as part of the schema upgrade: the event scheme set and retrieval-cleanup family, a time period month-offset repair, a null-quality repair, and an edit covering index.

These are repairs to data that was already incorrect. They run once, during the upgrade.

What to check. Where a month-offset problem had been producing wrong period boundaries, values may change after the repair. That is the point of it.

Upgrade path requirements#

Every machine in an instance must be upgraded together. Flow Config writes the schema version, so an older Flow Config will refuse an upgraded database and an older Bootstrap may not understand newly configured objects.

The schema upgrade is not reversible. The only rollback is a database restore plus reinstalling the previous version.

Maintenance entitlement is checked. An instance whose maintenance expiry predates this release cannot upgrade to it.

See Upgrading to Flow 7.2.0.

A short pre-upgrade check#

1. Do you use ordinal attribute lookups? Check their case matches.
2. Do you have scripts driving the CLI? Check exit-code handling, whether they call any gated verb, and whether they attach consumers to measures with more than one calendar.
3. Were any templates built by script on an earlier build? Verify their measures are template measures.
4. Do you publish via the MQTT consumer with model attribute placeholders? Confirm the resolved topics.
5. Do you have event schemes with retired periods? Expect duration measures to correct.
6. Do you rely on a template update to set an instance's Time Slice Aggregation? Set the new lock on the template.
7. Is your maintenance current?
8. Is your backup verified as restorable?

See also#

• Upgrading to Flow 7.2.0
• What's New in Flow 7.2.0
• Complete CLI Option Reference
• Exit Codes and Error Handling