-
Notifications
You must be signed in to change notification settings - Fork 225
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[ABCI]: catch up with 0.16.2 / 0.33.4 #233
Comments
Discovered in #232 |
Ah, this is due to the latest changes in That's why it started failing. The changes are fresh (release 5h ago). |
We can simply bump the version to fix this particular issue. But this reveals that the abci types and tests are out of date. Instead of manually keeping track of the types under Related issues: |
Proposes one solution to the underlying issue behind - informalsystems#249 - informalsystems#238 - informalsystems#233 My sense is that, if we want to set a strict abci version requirement for the rpc client, then we should put that in the source code itself. E.g., we might put a check on the client the abci version is within a version range which is known to be supported. If the version is outside that range, we could either error out or log errors/warning to alert users that we don't guarantee compatibility. The current approach of hardcoding in a version in the integration test tiself seems to create a lot of busy work due to uninformative test failures, and I'm not sure if delivers value. If the integration tests are meant to test that the RPC client integrates correctly with ACBI, should we really consider that integration has failed if everything works as expected while interfacing with an older (or newer) version?
Hardcoding a test for the version in this way makes it impossible to run the integration tests against different ABCI versions. This change proposes one solution to address this problem and to the underlying issue behind, e.g., - informalsystems#249 - informalsystems#238 - informalsystems#233 My sense is that, if we want to set a strict abci version requirement for the rpc client, then we should put that in the source code itself. E.g., we might put a check on the client that ensures the abci version is within a specified version range known to be supported. If the version is outside that range, we could either error out or log errors/warning to alert users that we don't guarantee compatibility. However, the current approach of hardcoding in a version in the integration test seems to create a lot of busy work due to uninformative test failures and it's not obvious what value it delivers. If the integration tests are meant to test that the RPC client integrates correctly with ACBI, should we really consider integration to have failed when everything works as expected while interfacing with an older (or newer) version? Signed-off-by: Shon Feder <shon@informal.systems>
Hardcoding a test for the version in this way makes it impossible to run the integration tests against different ABCI versions. This change proposes one solution to address this problem and to the underlying issue behind, e.g., - informalsystems#249 - informalsystems#238 - informalsystems#233 My sense is that, if we want to set a strict abci version requirement for the rpc client, then we should put that in the source code itself. E.g., we might put a check on the client that ensures the abci version is within a specified version range known to be supported. If the version is outside that range, we could either error out or log errors/warning to alert users that we don't guarantee compatibility. However, the current approach of hardcoding in a version in the integration test seems to create a lot of busy work due to uninformative test failures and it's not obvious what value it delivers. If the integration tests are meant to test that the RPC client integrates correctly with ACBI, should we really consider integration to have failed when everything works as expected while interfacing with an older (or newer) version? Signed-off-by: Shon Feder <shon@informal.systems>
Hardcoding a test for the version in this way makes it impossible to run the integration tests against different ABCI versions. This change proposes one solution to address this problem and to the underlying issue behind, e.g., - informalsystems#249 - informalsystems#238 - informalsystems#233 My sense is that, if we want to set a strict abci version requirement for the rpc client, then we should put that in the source code itself. E.g., we might put a check on the client that ensures the abci version is within a specified version range known to be supported. If the version is outside that range, we could either error out or log errors/warning to alert users that we don't guarantee compatibility. However, the current approach of hardcoding in a version in the integration test seems to create a lot of busy work due to uninformative test failures and it's not obvious what value it delivers. If the integration tests are meant to test that the RPC client integrates correctly with ACBI, should we really consider integration to have failed when everything works as expected while interfacing with an older (or newer) version? Signed-off-by: Shon Feder <shon@informal.systems>
* Add integration test pinned to tendermint-go v0.33 Closes #304 Also renames test-integration-ignored to test-integration-latest. With this change, CI runs two integration tests: 1. A `stable` test to protect against regressions, run against a pinned version of the tendermint/tendermint docker image. 2. A `latest` test to track whether we're maintaining parity with the latest development version of tendermint-go. Signed-off-by: Shon Feder <shon@informal.systems> * Remove test for hardcoded ABCI version Hardcoding a test for the version in this way makes it impossible to run the integration tests against different ABCI versions. This change proposes one solution to address this problem and to the underlying issue behind, e.g., - #249 - #238 - #233 My sense is that, if we want to set a strict abci version requirement for the rpc client, then we should put that in the source code itself. E.g., we might put a check on the client that ensures the abci version is within a specified version range known to be supported. If the version is outside that range, we could either error out or log errors/warning to alert users that we don't guarantee compatibility. However, the current approach of hardcoding in a version in the integration test seems to create a lot of busy work due to uninformative test failures and it's not obvious what value it delivers. If the integration tests are meant to test that the RPC client integrates correctly with ACBI, should we really consider integration to have failed when everything works as expected while interfacing with an older (or newer) version? Signed-off-by: Shon Feder <shon@informal.systems> * Update changelog Signed-off-by: Shon Feder <shon@informal.systems>
There seems to be a minor glitch in the integration tests:
The text was updated successfully, but these errors were encountered: