Skip to content

[Bug] - DeprecationWarning on instantiation of Client #114

Description

@cgearing

Hi there,

It looks like based on how the deprecations were implemented in #107 results in a DeprecationWarning on instantiating a client, e.g:

>>> config = {
...     "api_key": "your_api_key",
...     "nodes": [
...         {"host": "localhost", "port": "8108", "protocol": "http"}
...     ],
...     "connection_timeout_seconds": 2,
... }
>>> client = Client(config)
Deprecation warning: AnalyticsRulesV1 is deprecated on v30+. Use client.analytics instead.

It would be great for this not to happen, since it fills up logs with noise.

Activity

  1. tharropoulos commented on Nov 26, 2025

    @tharropoulos
    Collaborator

    Deprecation warnings only appear once per instance. You can also skip them through suppress_deprecation_warnings

  2. ianjosephwilson commented on Nov 28, 2025

    @ianjosephwilson

    What is the call to action on this warning? Are we somehow implicitly using the wrong analytic version?

  3. tharropoulos commented on Dec 1, 2025

    @tharropoulos
    Collaborator

    On versions v30+, accessing an old endpoint will either lead to validation errors (on Analytics) or resource missing errors (on Synonyms & Curation).

    We opted to have this deprecation warning be logged when instantiating the Client, so users don't have to deal with a stacktrace alongside the deprecation warning.

  4. Digma commented on Jan 16, 2026

    @Digma

    The warning makes it look like one is not using the library properly and using deprecated methods. I really feel like it would be good to remove them by default, or just for the specific methods that are deprecated, not the client itself

  5. lucas42 commented on Jan 29, 2026

    @lucas42

    Hi, I like to say I'd also find it useful if DeprecationWarnings were only logged when a deprecated feature is being used, rather than when instantiating the client.

    Having a stacktrace alongside a deprecation warning is actually really useful, especially for large codebases, as it makes it quicker to identify which part of the code is using the deprecated feature.

    When fixing up code which uses deprecated features, I find the best validation is to see deprecation warnings disappear from the logs. It seems with your current approach, these warnings will remain even after we've removed all the calls to deprecated stuff from our code? Or perhaps I'm misunderstanding how these work.

  6. tharropoulos commented on Jan 29, 2026

    @tharropoulos
    Collaborator

    Using said deprecated resources will lead to a 404 regardless. Since there is traction on this, we'll only log on those methods instead. Will provide a PR tomorrow.

  7. lucas42 commented on Jan 30, 2026

    @lucas42

    Amazing - thanks, @tharropoulos!

  8. jtmolon commented on Apr 28, 2026

    @jtmolon

    Hello!

    I ran into this issue while upgrading from v1.3.0 to v2.0.0, so I'm wondering if this is going to be fixed or if there's another recommended way to instantiate the sync client. I see there's an open PR but it's been stale for while.

    Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions