chore(history): populate process instance treepath

[HeleneW-dot]

related to #431

Pull Request Template

Description

Adds treepath migration for process instances.

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Refactoring (no functional changes)
• Test-only changes (no production code changes)

Testing Checklist

Black-Box Testing Requirements

• Tests follow black-box testing approach: verify behavior through observable outputs (logs, C8 API queries, real-world skip scenarios)
• Tests DO NOT access implementation details (DbClient, IdKeyMapper, ..impl.. packages except logging constants)
• Architecture tests pass (ArchitectureTest validates these rules)

Test Coverage

• Added tests for new functionality
• Updated tests for modified functionality
• All tests pass locally

Architecture Compliance

Run architecture tests to ensure compliance:

mvn test -Dtest=ArchitectureTest

If architecture tests fail, refactor your tests to use:

• LogCapturer for log assertions
• camundaClient.new*SearchRequest() for C8 queries
• Real-World skip scenarios (e.g., migrate children without parents)

Documentation

• Updated TESTING_GUIDELINES.md if adding new test patterns
• Added Javadoc comments for public APIs
• Updated README if user-facing changes

Checklist

• Code follows project style guidelines
• Self-reviewed the code
• Added comments for complex logic
• No new compiler warnings
• Dependent changes have been merged

Related Issues

[yanavasileva]

To avoid calling build(), can be also the patch can be generated after Line 106. If there's no rootProcessInstanceKey, users can use interception to populate the treePath. We do it in other places as well.

[venetrius]

I agree that calling build is not required here.
Consider tracking rootProcessInstanceKey in a local variable instead. The variable is already set in the block above (lines 100-108). Extracting it would be cleaner

[venetrius]

See my comments.
If treePath needs to contain the full hierarchy (all intermediate PI keys for deep structures like A→B→C), the current generateTreepath approach won't work. It only encodes root and current node.

Could you confirm whether deeper hierarchies are in scope?

[venetrius]

❌ If the hierarchy has more then 2 levels for example a chain A→B→C, process C's treePath would be PI_A/PI_C, skipping B.

[HeleneW-dot]

See the ticket description/slack link, the treepath is truncated to only keep root and leaf

[venetrius]

Sorry, I missed that 👍

[venetrius]

I agree that calling build is not required here.
Consider tracking rootProcessInstanceKey in a local variable instead. The variable is already set in the block above (lines 100-108). Extracting it would be cleaner

[HeleneW-dot]

If treePath needs to contain the full hierarchy (all intermediate PI keys for deep structures like A→B→C), the current generateTreepath approach won't work. It only encodes root and current node.
Could you confirm whether deeper hierarchies are in scope?

We only keep the truncated treepath with root and leaf, I documented this in the ticket together with the slack link for the discussion around this question

[venetrius]

👍 Looks good to me!