Bump jackson-databind from 2.10.0.pr1 to 2.12.7.1

[dependabot[bot]]

Bumps jackson-databind from 2.10.0.pr1 to 2.12.7.1.

Commits

• See full diff in compare view

You can trigger a rebase of this PR by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
• @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
• @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
• @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
• @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

> **Note** > Automatic rebases have been disabled on this pull request as it has been open for over 30 days.

[alexmojaki]

It sounds like you wrote code like this:

try:
    ...
except Exception as e:
    logfire.exception(e)

logfire.msg_template refers to that first argument of logfire.exception, it has to be a string. You can write logfire.exception("Failed to do jobs") and the exception itself will be picked up automatically.

[lironsam]

Actually, I don't use logfire.exception(e) unless I'm mistaken.

class JobsNumberMinimumException(DataQualityException):
    def __init__(self, message=""):
        super().__init__(message)
        
class DataQualityException(Exception):
    """
    Base exception for data quality issues.
    """

    def __init__(self, message: str):
        self.message = message
        super().__init__(self.message)

 

if len(jobs) <= self.number_minimum_jobs
            raise JobsNumberMinimumException(f"not enough jobs: {len(jobs)} over "
                                                     f"the requirements needed: {self.number_minimum_jobs}")

Inside JobsNumberMinimumException, it's a string.

[alexmojaki]

But where's the code where you used logfire?

[lironsam]

So far, I've juste integrated Logfire with the standard library logging module (logging). It works fine for most of my process but on this case it works until I get to the exception level, the code above.

[alexmojaki]

OK, this makes sense. There must be some code doing this:

import logging
logger = logging.getLogger(...)

try:
    ...
except Exception as e:
    logger.<log method>(e)

This is a bug that we should fix ASAP by converting log_record.msg to a string in the logging integration. In the meantime, if you can identify those logging calls, you can ensure that they receive a string instead to resolve the error.

[alexmojaki]

In fact it should be noted that even after the fix it would be best to ensure that you pass a string where possible describing the general problem. Otherwise it will be hard when viewing/querying logs to group together all logs coming from this location if they have different error messages, and it will also be hard to distinguish between similar exceptions being logged from different places.

[lironsam]

I'll take a look but I don't think that I have any logger.(e) inside my except. That's why I'm confused especially for my case where I don't see one.

Thank for your recommendation.

Do you think that this string as an example is a bad practice: f"not enough jobs: {len(jobs)} over the requirements needed: {self.number_minimum_jobs}" ?

[alexmojaki]

I'll take a look but I don't think that I have any logger.(e) inside my except. That's why I'm confused especially for my case where I don't see one.

It's probably inside a library somewhere.

Do you think that this string as an example is a bad practice: f"not enough jobs: {len(jobs)} over the requirements needed: {self.number_minimum_jobs}" ?

No it's not bad practice, but also it makes no difference to logfire.

[alexmojaki]

New version of the SDK should fix this.