The clamp discovery is the best part of this, and it generalizes past Plant 3D. Any tool that validates or bounds input before it draws, executes, or renders it will hand back the typed value through its API, not the applied one, and the two diverge exactly where somebody hit a limit, which is also exactly the case that matters most downstream. Reading the bounds out of the vendor's own script at runtime instead of hardcoding them is the right call for the reason you gave, since scripts get edited and hardcoded copies rot, but it also means the plugin now has an implicit dependency on that file staying regular enough to parse as an if/assignment pair. Did you consider a canary check - re-derive one known support's clamped value from your own read of the limits and compare it against what SupportHelper actually reports, on a schedule, so a vendor patch that reformats the .py breaks loudly instead of silently going back to reporting typed values as if they were real ones?
Mihai, you hit the nail on the head. The implicit dependency on the vendor's coding style (the if/assignment pair) is indeed the fragile link in this chain. If a patch reformats that file, the silent failure mode is catastrophic downstream because the pipeline would confidently trust corrupt data.
I hadn't thought about the canary check at all, but your proposal is the missing guard needed to make this completely bulletproof in corporate production. Implementing a scheduled verification against a hardcoded, known baseline model to compare the parsed bounds vs what SupportHelper reports is the exact definition of a clean circuit breaker here.
I’m definitely going to bake that canary routine into the orchestrator next week to make it fail loudly if Autodesk alters the script layout. Thanks for the insight—this is exactly the type of architecture review I was hoping for when writing this up. Appreciate the feedback
The clamp discovery is the best part of this, and it generalizes past Plant 3D. Any tool that validates or bounds input before it draws, executes, or renders it will hand back the typed value through its API, not the applied one, and the two diverge exactly where somebody hit a limit, which is also exactly the case that matters most downstream. Reading the bounds out of the vendor's own script at runtime instead of hardcoding them is the right call for the reason you gave, since scripts get edited and hardcoded copies rot, but it also means the plugin now has an implicit dependency on that file staying regular enough to parse as an if/assignment pair. Did you consider a canary check - re-derive one known support's clamped value from your own read of the limits and compare it against what SupportHelper actually reports, on a schedule, so a vendor patch that reformats the .py breaks loudly instead of silently going back to reporting typed values as if they were real ones?