I was wondering if we really need to support SET_VERSIONSTAMPED_VALUE v1 format in our language bindings?
For the rust binding that I am currently working on, I plan on supporting API version 630 and beyond only (Btw, I am really looking forward to FDB 7.0 release. )
It looks like api.py automatically injects tests for v1 format here. (I spent a week tracking this down, as I assumed the test failure was a bug in my binding layer. In the process I experienced first hand what makes FDB testing special. )
How are you specifying the command for your tester? If you define it in known_testers.py, then I think you can also specify a minimum API version it can use for a test. If it uses only newer API versions, then it shouldn’t generate versionstamp operations using the old format.
I don’t think it’s possible to specify a minimum API version if you pass in the command for the tester directly in the binding tester arguments, though that’s probably something that could be easily changed. It is possible to choose an exact API version to use this way, if you wanted.
bindingtester.py rust --test-name api --compare --num-ops 1000 --logging-level WARNING 2>&1
I am using known_testers.py. As you can see from here, I’ve increased the minimum API version to 630 for python tester.
However, it is still generating versionstamp tests for older format. I think that is because the if condition here in api.py generates v2 tests if API version >= 520, but defaults to generating v1 tests in any case.
Once I removed the default generation of v1 tests in the imported version of api.pyhere, tests started to pass.
That looks right for the definition for the rust tester, and it shouldn’t be necessary to modify the minimum API version of any other tester.
The test that you linked is still intended to be generating the correct format based on the API version. If you look at the definition of versionstamp_value, it is written to be conditional on the API version to choose which one to use.
That said, it is possible that the thing that is failing is somewhere here rather than in your test. You might have to instrument either this or your test a bit to see what’s going on.