Regression: non-tabular OIDs respond with `noSuchInstance` even when my handler sets a value

[thom-nic]

Regression from 3.15 -> 3.19.1

I tracked this down to a change introduced in 161849c

Specifically, the method signature of MibNode.prototype.setValue was changed so the first argument is typeFromSet instead of newValue. We call this method when we dynamically set OID values from a handler.

Mark, what's your versioning policy, and should it be expected for a minor version change to introduce incompatible changes?

I can adapt my code, but I'm opening this issue to call out the breaking change in case anyone else runs into this same issue when upgrading.

I also ran into several other issues during upgrade where constraint validation failed but that was because I was trying to set a value that legit violated the MIB constraints. This is my problem but it's still an unexpected/ breaking change for a minor version bump. It would have been nice to have an option to disable the constraint checking/ maintain the old behavior for compatibility but at this point I've resolved most of the issues.

Actually I see a third problem here but I'll open a separate issue for that.

[markabrahams]

Hi @thom-nic - thanks for raising this. My versioning policy is semantic version (ala https://semver.org) with one deviation: I do employ discretion to reclassify "patch" changes as "minor" if I feel the scope of a change and/or the perceived risk of a change is sufficiently high.

If you read the API docs (in README.md) as the public API reference, then you'll notice that MibNode is not included in the public API - at the moment at least. The fact that MibNode has a private API isn't enforced in code; indeed it isn't even obvious from looking at the code, given that it is currently JavaScript and doesn't enjoy the access modifiers "public" and "private" available in TypeScript (completion of open issue #129 would serve to resolve that particular problem).

Since MibNode doesn't currently expose a public API, it isn't subject to major version change restrictions. There is a reasonable argument that its API should be public, but it isn't currently, and that is why a change to the MibNode wasn't classified as a breaking/major change.

The constraints introduction is a separate issue. This was a fix for Issue #214 that perhaps could have included a feature toggle. Although incremental improvement in data validation and error checking has historical happened fairly frequently in the project without such a toggle, I can see an argument for this with hindsight. I think from where we are now though, as you alluded to, we will proceed without a toggle here, as the overarching goal of data validation is to produce a safer system all round, and - when implemented well! - this should benefit everyone!

[thom-nic]

Hey Mark, thanks for the clarification. I would humbly request that MibNode be added to the public API - it is critical to our reactive OID updates via handlers! I will check the codebase to see if we are leveraging any other functionality that is not documented in the README as well.