Confusing behaviour of trackingPlans[].version field

[PeterJCLaw]

The trackingPlans[].version field, while not mentioned in the README, appears to be a way to control which version of a tracking plan is used to generate the client code. Setting it to a number larger than the latest tracking plan version results in an error when npx rudder-typer update is run, seeming to confirm that the specific version is being downloaded.

However setting it to any valid version always results in the latest version of the tracking plan being downloaded -- at least as far as the content of the plan goes. Unfortunately the version provided is what ends up in the resulting plan.json file, even if the rest of the content of the file reflects a different plan version.

In turn this means that the generated client code contains the version number from the config, which presumably would lead to events being sent by that generated code being validated against a different version of the tracking plan than was expected.

[contributor-support]

Thanks for opening this issue! We'll get back to you shortly. If it is a bug, please make sure to add steps to reproduce the issue.

[akashrpo]

Hi @PeterJCLaw,

Thank you for raising this issue!

RudderTyper currently supports only the latest version of the tracking plan. We’re particularly interested in understanding your use case for utilizing historical versions of the tracking plan. Could you share more details about why this functionality would be helpful for your workflows?

[PeterJCLaw]

@akashrpo thanks for the response. There's a couple of things here: a reproducibility use-case and correctness of the generated code.

Currently the code generated by the config I've described here is, I believe, actually wrong relative to the state of the Tracking Plans in the RudderStack instance. That is -- the generated plan code can claim to be (and will thus send payloads claiming to be) for one version, when the code (and resulting payloads) are for another version. Unless I've missed something in how the generated code behaves (unfortunately I haven't tested it), this will result in invalid payloads being received and thus rejected despite those payloads having come from code which was generated without any form of warning.
I realise this isn't what you asked about, but I wanted to make it clear that the current behaviour creates this bug in the generated code.

As for why I want to set the version field -- that's to enable reproducibility. Explicit is better than implicit.

Ideally I'd like to be able to use RudderTyper such that the generated plan is updated only when explicitly asked to do so (rather than on every run), while still enabling validating that the plan being used to generate code is itself correct and unmodified.

For example the Sources' CI might run validation that the plan is valid and the code generated matches the plan, both of which necessitate running RudderTyper but don't expect the code to actually change. This sort of thing is very useful when generated code is committed to a repo as it ensures that accidental manual changes to the code do not happen and that any changes to the config are associated with proper changes to the generated code. An comparable example of this in a different context would be like running a package manager's lock command (without updates) to ensure that the input dependencies list aligns with the locked dependencies list (but without checking for updated versions).

In turn, this would allow for cases where a single plan is shared by multiple sources but without requiring all sources to immediately update their code when the plan changes. However it is useful even if only one Source/Tracking Plan is present, since reproducible builds are generally useful. Another case might be if a change needs to be reverted -- it's easier to be able to do that purely from the client rather than needing to also coordinate for the Tracking Plan changes to need to be undone etc.

[akashrpo]

Hi @PeterJCLaw,

Thank you for the detailed explanation!
We’re tracking this as a feature for adding versioning in our tracking plan Events APIs to support these use cases better.