Skip to content
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

fix: include txid in more failure logs #4396

Merged
merged 15 commits into from
Nov 6, 2024

Conversation

janniks
Copy link
Contributor

@janniks janniks commented Feb 20, 2024

Description

Adds txid to more failure logs for better interpretability of logs in production.

Additional info (benefits, drawbacks, caveats)

Can be used for better understanding what happened to a tx given a txid and logs.

Checklist

  • Test coverage for new or modified code paths
  • Changelog is updated
  • Required documentation changes (e.g., docs/rpc/openapi.yaml and rpc-endpoints.md for v2 endpoints, event-dispatcher.md for new events)
  • New clarity functions have corresponding PR in clarity-benchmarking repo
  • New integration test(s) added to bitcoin-tests.yml

@janniks janniks self-assigned this Feb 20, 2024
@janniks janniks changed the title fix: include txid in failure logs fix: include txid in more failure logs Feb 20, 2024
@janniks janniks added the chore Necessary but less impactful tasks such as cleanup or reorg label Feb 20, 2024
Copy link

codecov bot commented Feb 20, 2024

Codecov Report

Attention: Patch coverage is 11.62791% with 38 lines in your changes are missing coverage. Please review.

Project coverage is 26.37%. Comparing base (aaaca77) to head (3fff50b).
Report is 175 commits behind head on develop.

❗ Current head 3fff50b differs from pull request most recent head 86dd3df. Consider uploading reports for the commit 86dd3df to get more accurate results

Files Patch % Lines
stackslib/src/chainstate/stacks/db/transactions.rs 11.90% 37 Missing ⚠️
stackslib/src/chainstate/stacks/miner.rs 0.00% 1 Missing ⚠️
Additional details and impacted files
@@             Coverage Diff              @@
##           develop    #4396       +/-   ##
============================================
- Coverage    56.00%   26.37%   -29.63%     
============================================
  Files          465      404       -61     
  Lines       336186   293090    -43096     
============================================
- Hits        188266    77290   -110976     
- Misses      147920   215800    +67880     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Copy link
Member

@jcnelson jcnelson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey, we don't open PRs into master directly unless it's a hotfix or a release. Can you instead open this against develop?

@janniks
Copy link
Contributor Author

janniks commented Feb 21, 2024

Apologies, forgot to switch 👍🏻 Will update

@janniks janniks force-pushed the Add-txid-to-post-condition-check branch from 75dbfbd to 94b5ce8 Compare February 26, 2024 13:09
@janniks janniks changed the base branch from master to develop February 26, 2024 13:09
jbencin
jbencin previously approved these changes Feb 27, 2024
jcnelson
jcnelson previously approved these changes Feb 27, 2024
@jcnelson
Copy link
Member

Just make sure CI passes

@janniks
Copy link
Contributor Author

janniks commented Mar 4, 2024

Right now tests are failing because some auto-generated contract names are too long. e.g. a contract name from setting up the test observer; blockstack_lib-chainstate-stacks-boot-pox_3_tests-pox_3_getters
Unfortunately, Txid serializes and panics on failure.

@jbencin any ideas on how to go about this, or point me to the correct code. e.g. if the exact string isn't important, we can slice it to the max contract length, or something similar.

@jbencin
Copy link
Contributor

jbencin commented Apr 10, 2024

@jcnelson @janniks I found the issue. ContractName is implemented using a macro, like this:

guarded_string!(
    ContractName,
    "ContractName",
    CONTRACT_NAME_REGEX,
    MAX_STRING_LEN,
    RuntimeErrorType,
    RuntimeErrorType::BadNameValue
);

MAX_STRING_LEN is 128, so it's possible to construct a ContractName with up to 128 characters. However, when we implement StacksMessageCodec for ContractName:

    fn consensus_serialize<W: Write>(&self, fd: &mut W) -> Result<(), codec_error> {
        if self.as_bytes().len() < CONTRACT_MIN_NAME_LENGTH as usize
            || self.as_bytes().len() > CONTRACT_MAX_NAME_LENGTH as usize
        {
            // Error!
        }
        // ...
    }

CONTRACT_MAX_NAME_LENGTH is 40, much smaller than MAX_STRING_LEN. This means that ContractName::try_from() allows us to create structs that can't be serialized

Proposed solutions

  • Change the macro to use CONTRACT_MAX_NAME_LENGTH instead of MAX_STRING_LEN. This won't actually fix the problem, and will likely expose more invalid ContractNames that were never being serialized, but it will make invalid ContractNames easy to find and fix. Where it fails, we can replace ContractName::try_from() with ContractName::try_from_truncated()
  • Change CONTRACT_MAX_NAME_LENGTH to match MAX_STRING_LEN. Probably not what we want to do, but would fix the issue immediately

# Conflicts:
#	stackslib/src/chainstate/stacks/db/transactions.rs
@janniks janniks dismissed stale reviews from jbencin and jcnelson via 863490a May 6, 2024 10:42
@janniks
Copy link
Contributor Author

janniks commented May 6, 2024

Updated the test helpers to not allow invalid contract name generation. (Capping at CONTRACT_MAX_NAME_LENGTH and remove leading dashes). This way tests shouldn't fail due to the logging of txids, while in production no unserializable txs should reach this code.

stackslib/src/net/mod.rs Outdated Show resolved Hide resolved
@jcnelson
Copy link
Member

jcnelson commented May 6, 2024

@jbencin @janniks This finding belongs in an issue and should be tackled by a separate PR. Thanks! 🙏

@jbencin
Copy link
Contributor

jbencin commented May 6, 2024

@jcnelson Already made an issue, #4727

We are modifying the PR to avoid the issue for now

# Conflicts:
#	stackslib/src/net/mod.rs
@janniks janniks requested a review from a team as a code owner October 14, 2024 13:38
Copy link
Contributor

@obycode obycode left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎉

@obycode obycode requested a review from jcnelson November 6, 2024 16:40
@obycode obycode added this pull request to the merge queue Nov 6, 2024
Merged via the queue into develop with commit ebe6adb Nov 6, 2024
130 checks passed
@blockstack-devops
Copy link
Contributor

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@stacks-network stacks-network locked as resolved and limited conversation to collaborators Nov 14, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
chore Necessary but less impactful tasks such as cleanup or reorg locked
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants