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

LogSeverity not exported from @google-cloud/logging. #1402

Open
RastogiAbhijeet opened this issue Feb 2, 2023 · 3 comments · May be fixed by #1485
Open

LogSeverity not exported from @google-cloud/logging. #1402

RastogiAbhijeet opened this issue Feb 2, 2023 · 3 comments · May be fixed by #1485
Labels
api: logging Issues related to the googleapis/nodejs-logging API. priority: p3 Desirable enhancement or fix. May not be included in next release. type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design.

Comments

@RastogiAbhijeet
Copy link

Thanks for stopping by to let us know something could be better!

PLEASE READ: If you have a support contract with Google, please create an issue in the support console instead of filing on GitHub. This will ensure a timely response.

  1. Is this a client library issue or a product issue?
    It is a client library issue

  2. Did someone already solve this?
    No.

  3. Do you have a support contract?
    It's client-lib related issue.

If the support paths suggested above still do not result in a resolution, please provide the following details.

Environment details

  • OS: MacOS 13.2 (22D49)
  • Node.js version: 18.12.1
  • npm version: 8.19.2
  • @google-cloud/logging version: 10.3.3

Steps to reproduce

  1. Import { LogSeverity } from "@google-cloud/logging" not exported

Making sure to follow these steps will guarantee the quickest resolution possible.

image

Thanks!

@RastogiAbhijeet RastogiAbhijeet added priority: p2 Moderately-important priority. Fix may not be included in next release. type: bug Error or flaw in code with unintended results or allowing sub-optimal usage patterns. labels Feb 2, 2023
@product-auto-label product-auto-label bot added the api: logging Issues related to the googleapis/nodejs-logging API. label Feb 2, 2023
@losalex losalex added type: question Request for information or clarification. Not an issue. and removed type: bug Error or flaw in code with unintended results or allowing sub-optimal usage patterns. labels Feb 3, 2023
@losalex
Copy link
Contributor

losalex commented Feb 3, 2023

Thanks @RastogiAbhijeet for opening this issue!
Can you please clarify why you need a direct reference for LogSeverity? What are you plans for using it?

@RastogiAbhijeet
Copy link
Author

RastogiAbhijeet commented Feb 4, 2023

Hey @losalex ,

My use case is pretty straightforward,
I want to enforce a strict type on the severity argument passed to the wrapper function I have written for the writing logs to Cloud Run stdout.

Currently the Severity enum exported by the @gooogle-cloud@logging node-module is mapping to numbers.

# Referred from the node modules
export declare enum Severity {
    emergency = 0,
    alert = 1,
    critical = 2,
    error = 3,
    warning = 4,
    notice = 5,
    info = 6,
    debug = 7
}

I can maybe also use SeverityName which can help me to get the severity names ( as I would expect ) but it does so in the lower case.

But the issue with both cases is that the severity is not properly reflected in the Cloud Log Explorer in the GCP console.

So for eg:
I pass -> 2 for critical severity, the cloud log shows it as Severity "Default".

Now if you look at this link, it will show the correct number that should be used for the severity. https://cloud.google.com/logging/docs/reference/v2/rest/v2/LogEntry#logseverity.


Another reason why I started to chase LogSeverity is because as I digged into the
LogEntry Type in the node-module, you'd see that the severity in the metadata says -> LogSeverity and not Severity.

export type LogEntry = Omit<google.logging.v2.ILogEntry, 'timestamp' | 'severity' | 'httpRequest'> & {
    timestamp?: Timestamp | null;
    severity?: LogSeverity | null;
    httpRequest?: HttpRequest | null;
};

Ofcourse, I might be looking at the wrong place but how the types are being managed so of didn't make a lot of sense.

Honestly, I would label this as a bug and hope it gets fixed.


Hope it helps. Happy to chat through it if anything above didn't make sense.

@Abhi347
Copy link

Abhi347 commented Feb 21, 2023

If you are interested in just the enum type, you can try something like

import { Entry } from '@google-cloud/logging';

export type LogSeverityType = Exclude<
  NonNullable<Entry['metadata']['severity']>,
  string
>;

But if you want the enum values, I am not sure if that's possible without explicit export. I asked this SO question in case it's possible.

@meredithslota meredithslota added type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design. and removed priority: p2 Moderately-important priority. Fix may not be included in next release. type: question Request for information or clarification. Not an issue. labels Apr 27, 2023
@losalex losalex self-assigned this May 30, 2023
@losalex losalex added the priority: p3 Desirable enhancement or fix. May not be included in next release. label May 31, 2023
@losalex losalex removed their assignment Jul 3, 2023
@cindy-peng cindy-peng linked a pull request Jan 22, 2024 that will close this issue
4 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api: logging Issues related to the googleapis/nodejs-logging API. priority: p3 Desirable enhancement or fix. May not be included in next release. type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants