bpm: a process variable started as a whole number stays whole (#7373) - #7422
Merged
Merged
Conversation
A process started through `Process.start(key, businessKey, json)` had its variables read with the platform's default Gson, which types every untyped JSON number as a `Double`. So a record's primary key handed over as `33` landed in Flowable's variable store as `33.0`, and every reader that renders such a variable as text said so: an Inbox row's subject locator read "33.0", which the generated controller's integer path parameter then refused - the card could not load the very record the task is about. The variables of a start and of a task completion are now read with the LONG_OR_DOUBLE number strategy: a JSON number with no fractional part is an integer, a genuine decimal stays a decimal. Generated delegates were never affected (they read the key as `((Number) key).longValue()`), which is why the symptom was confined to the one path that renders the key as text. An instance started before this fix still carries the widened key, so the subject reads it as the whole number it is rather than leaving those tasks broken until their process ends. Fixes #7373 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Cause
Process.start(key, businessKey, json)reachedBpmProviderFlowable.startProcess(String), which read the variables with the platform's default Gson (GsonHelper.fromJson(parameters, HashMap.class)). Gson types every untyped JSON number as aDouble, so a record's primary key handed over by the generated trigger as33landed in Flowable's variable store as33.0.Every reader that renders such a variable as text then says so.
TaskSubjectis one: an Inbox row's subject locator read"33.0", and the generated controller is bound on an integer path parameter, so the subject card's own fetch came back asInvalid value for path parameter [id]: 33.0- the card could not load the very record the task is about.Generated delegates were never affected: they read the key as
((Number) key).longValue(). That is why the symptom was confined to the one path that renders the key as text, and why it was silent in every layer that does not click the card.Change
ProcessVariables.fromJsonreads a variables document with Gson'sLONG_OR_DOUBLEnumber strategy: a JSON number with no fractional part is an integer, a genuine decimal stays aDouble. Both sites that take variables as JSON use it - starting a process and completing a task (TaskServiceImpl.completeTask(String, String), which had the same widening for a form's integer field).TaskSubjectreads the key as the whole number it is. An instance started before this fix still carries the widened key, and leaving those tasks broken until their process ends is not a fix.Verification
mvn -pl components/engine/engine-bpm-flowable test- 45 tests green, including the three new ones. Each was checked to FAIL with the fix backed out (number strategy restored toDOUBLE, the subject reading the raw value):ProcessVariablesTest(the parse),ProcessVariablesEngineTest(a real Flowable engine - the store types the variable from the value it is handed, so the round trip is the claim),TaskSubjectTest(an already-running instance's widened key).mvn -P integration-tests -pl tests/tests-integrations verify -Dit.test=IntentEmissionCoverageIT- green (195 s). Its ui: Inbox rows carry no business identity (only 'Ref <id>') and the Personal shell Inbox lists every back-office group task #7077 subject block now also asserts the servedsubject.idis a whole number, which is the end-to-end statement: the trigger starts the process, the task listing serves the locator, and the id is what the generated controller's path parameter accepts.mvn formatter:validatewith the cache wiped, and thereleaseprofile javadoc build on the changed module.Not verified: the full IT suite, and no behaviour was checked on PostgreSQL (nothing here is SQL).
Fixes #7373
🤖 Generated with Claude Code