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

HTTP status code selection does not allow 0 #5355

Open
1 task done
julianbraasch opened this issue Nov 18, 2024 · 5 comments
Open
1 task done

HTTP status code selection does not allow 0 #5355

julianbraasch opened this issue Nov 18, 2024 · 5 comments
Labels
area:monitor Everything related to monitors bug Something isn't working type:enhance-existing feature wants to enhance existing monitor

Comments

@julianbraasch
Copy link

📑 I have found these related issues/pull requests

None

🛡️ Security Policy

Description

I'm using the gRPC keyword monitor type which I would like to connect to a ChirpStack instance.
I did confirm that my proto file and method are correct by using Postman for the same request. I noticed that Postman lists "0 OK" as the status code of the response. However, I am unable to add 0 as my desired status code in Uptime Kuma. I am not sure if this is actually the reason why this monitor fails.

👟 Reproduction steps

Add new gRPC monitor

👀 Expected behavior

The monitor returns the response of my proto service

😓 Actual Behavior

The monitor reports a failed connection. Ping statistics are available through. No entries in the event list of the monitor itself.

🐻 Uptime-Kuma Version

1.23.15

💻 Operating System and Arch

macOS 15.1

🌐 Browser

Google Chrome 130.0.6723.119

🖥️ Deployment Environment

  • Runtime: Docker 4.35.1
  • Database: Docker volume
  • Filesystem used to store the database on: APFS on a SSD
  • number of monitors: 1

📝 Relevant log output

[MONITOR] WARN: Monitor #1 'ChirpStack': Failing: Error in send gRPC 8 Received message larger than max (1752460652 vs 4194304) | Interval: 20 seconds | Type: grpc-keyword | Down Count: 0 | Resend Interval: 0
@julianbraasch julianbraasch added the bug Something isn't working label Nov 18, 2024
@CommanderStorm
Copy link
Collaborator

Received message larger than max

What is the message that the grpc endpoint is responding with?

@julianbraasch
Copy link
Author

The result JSON contains a single entry called jwt which contains a JSON Web Token, which admittedly can be quite long

@CommanderStorm
Copy link
Collaborator

If the message is referring to bits, that would be 219 MB.
If it's bytes that would be 1.7GB

Having a limit against such requests is reasonable.
In postman what is the size of the message in MB?

@julianbraasch
Copy link
Author

julianbraasch commented Nov 19, 2024

I concur with enforcing request limits, but I can assure you they are orders of magnitude lower. The response in Postman was just 250 bytes long.

{
    "jwt": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJhdWQiOiJjaGlycHN0YWNrIiwiZXhwIjoxNzMyMDk3MDc3LCJpc3MiOiJjaGlycHN0YWNrIiwic3ViIjoiMDUyNDRmMTItNmRhZi00ZTFmLTgzMTUtYzY2NzgzYTBhYjU2IiwidHlwIjoidXNlciJ9.ZnWatLRzzb3EMo5VVEes-3wzhD3ePJpqt02zqyGnmSs"
}

@CommanderStorm
Copy link
Collaborator

Interesting.
So not really exceeding the limit...

@CommanderStorm CommanderStorm added area:monitor Everything related to monitors type:enhance-existing feature wants to enhance existing monitor labels Nov 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:monitor Everything related to monitors bug Something isn't working type:enhance-existing feature wants to enhance existing monitor
Projects
None yet
Development

No branches or pull requests

2 participants