Skip to content
This repository was archived by the owner on Aug 13, 2026. It is now read-only.
This repository was archived by the owner on Aug 13, 2026. It is now read-only.

Arguments for list_entries are confusing #136

Closed

Description

@daniel-sanche

client.list_entries takes in page_size and page_token arguments. It's not clear to me what a page_token should look like, and page size doesn't seem to have an affect (it says it should determine the "maximum number of entries to return", but that doesn't seem true).

We should look into these and make sure they are well tested and documented

b/174842529

Activity

  1. added
    priority: p2Moderately-important priority. Fix may not be included in next release.
    type: feature request‘Nice-to-have’ improvement, new feature or different behavior or design.
    and removed
    triage meI really want to be triaged.
    on Dec 21, 2020
  2. added this to the v3.0.0 milestone on Jan 13, 2021
  3. bbayles commented on Feb 11, 2021

    @bbayles

    Another problem: if an error is encountered during paging, there seems to be no way to resume from where you were. list_entries returns a generator now, which doesn't allow access to the page_token.

  4. daniel-sanche commented on Feb 11, 2021

    @daniel-sanche
    ContributorAuthor

    What kind of error are you running into? Do you have any code that can replicate the issue?

  5. bbayles commented on Feb 11, 2021

    @bbayles

    Suppose I do:

    for flow_entry in logging_client.list_entries(
        filter_='whatever filters',
        resource_names=[f'projects/whatever-project'],
    ):
        pass

    This handles paging for me, but if one of the page calls returns a 429 (slow down), I'm stuck - I can't resume paging from where I was without stating over from the first page. (set a small page size to be more likely to hit the API limit)

    Or can I? I would love to be wrong on this. If I am, how would I get the page_token?

  6. bbayles commented on Feb 11, 2021

    @bbayles

    To say it more generally: list_entries does paging for me. Suppose that one of the calls during paging fails for any reason. Does the current implementation of list_entries allow me to recover without starting over? If it does, it's not at all clear from the docs or source.

  7. daniel-sanche commented on Feb 11, 2021

    @daniel-sanche
    ContributorAuthor

    That's a good question. I'm going to try to look into improving the way list_entries is handled when I have a chance. unfortunately since it's an API breaking change, any changes will have to wait for the next major release, and likely not this quarter.

    If this is causing issues in your work now, you can look into using the low-level auto-generated LoggingServiceV2Client.list_log_entries directly. It's not as idiomatic and harder to work with than the regular logging_client.list_entries, but it should give you more control

  8. bbayles commented on Feb 11, 2021

    @bbayles

    Many thanks. Could you explain succinctly what list_log_entries is vs. list_entries? The latter does not actually call the former, from what I can tell.

    For what it's worth, the old version of this library (before v2) worked! The pager returned by list_entries kept track of the next_page_token.

  9. daniel-sanche commented on Feb 11, 2021

    @daniel-sanche
    ContributorAuthor

    For context, we use automated code generation to generate the majority of GCP client libraries. But for some like logging, we added an idiomatic layer on top to better integrate with language features (for Python, we want you to be able to send logs using the standard 'logging' library, etc). list_log_entries is the autogenerated layer, and list_entires is a higher-level client built on the other.

    Eventually we want the handwritten layer to be used for 100% of tasks, but we have some work to do before it's fully there.

    If you follow the call stack, youll see list_enteries calls self.logging_api.list_entries, then logging_api calls _gapic.make_logging_api, which creates a LoggingServiceV2Client instance.

    Before 2.0, you were likely using just the auto-generated code, The autogenerated and hand-written code used to live in different folders, but we combined them in the latest release

  10. bbayles commented on Feb 12, 2021

    @bbayles

    Thanks for the help - I see the connection to list_log_entries now. Note that your link goes to some tests, however.

    Could I request that the v2 docs be updated to point out that errors during paging are fatal? If this had been in the UPGRADING document I would not have upgraded!

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

Metadata

Metadata

Assignees

Labels

api: loggingIssues related to the googleapis/python-logging API.priority: p2Moderately-important priority. Fix may not be included in next release.type: feature request‘Nice-to-have’ improvement, new feature or different behavior or design.

Type

No type

Projects

No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions