I'm working on implementing opsgenie for the first time, with a new airflow instance. I have been unable to receive alerts so far, even though everything seems to be correctly set up.
I already have my account/team and integrations (slack and api) set. I already configured the opsgenie conection in airflow (using the slack api key as password). An I already added the opsgenie hook to my code.
It all seems to work ok. According to the airflow logs, the opsgenie genie request is correctly sent. I even get responses like this:
Sending 'POST' to url: https://api.opsgenie.com/v2/alerts
<Response [202]>
{'result': 'Request will be processed', 'took': 0.007, 'requestId': '65f2a665-40ea-4173-967e-xxxxxxxxxx'}
If I search for the request id, I get this response:
{
"data": {
"success": true,
"action": "Create",
"processedAt": "2023-01-03T16:40:03.08Z",
"integrationId": "xxx",
"isSuccess": true,
"status": "Created alert",
"alertId": "xxx",
"alias": "ECO_OPSGENIE_ALERTS-send_opsgenie_alerts-20230103"
},
"took": 0.004,
"requestId": "65f2a665-40ea-4173-967e-xxxxxxxxxx"
}
However, NO alerts are ever sent, and I can't see them anywhere in the opsgenie alerts section. And of course I also get bothing on slack or on the opsgenie app.
If I create a "manual" alert using the opsgenie app, I do get slack and app alerts... but nothing using the API.
I also tried directly from postman, but same thing: no alerts are sent, even though the response says they were correctly created.
Any idea what could be causing this and how to solve it?
Not sure if anyone will need this, but I solved it. I had to add this parameter to the request's body:
"responders": [
{
"name": team_name,
"type": "team"
}
]
team_name is the name of my configured team in opsgenie. That's it. Now it's all working.
Related
I am developing a Smart Home Action for Google Home, and I am trying to use the Test Suite to test the handling of EXECUTE intents sent to my fulfilment URI in the backend. I have successfully linked a test account and can populate the test cases with devices and traits (actions.devices.SHOWER devices)
However, when testing the StartStop trait, the Test Suite does not ever send an EXECUTE intent to the fulfilment URI to attempt to Start/Stop the device. The QUERY intent that is triggered after this test case fails is received correctly by my backend: see the test case screen
I have verified that the test case passes if I manually perform the necessary device state update and trigger a report state via Google Homegraph API while this "Start the Office" command is running. But I can see from my Http request logs that I never receive an EXECUTE intent, nor are there any entries in the Cloud Console logs showing an attempt to call the backend.
I have attempted re-linking my account, and using multiple test accounts but this behaviour does not change. The response I am sending to the SYNC is
{
"requestId": "9346220314501836318",
"payload": {
"devices": [
{
"id": "1002",
"type": "action.devices.types.SHOWER",
"traits": [
"action.devices.traits.StartStop",
"action.devices.traits.TemperatureControl"
],
"name": {
"name": "Office"
},
"attributes": {
"temperatureRange": {
"minTemperatureCelcius": 0,
"maxTemperatureCelcius": 60
},
"temperatureUnitForUX": "C",
"commandOnlyTemperatureControl": true,
"temperatureStepCelcius": 1,
"pausable": false
},
"willReportState": true,
"deviceInfo": {
"manufacturer": "REMOVED",
"model": "TestModel",
"hwVersion": null,
"swVersion": null
}
}
],
"agentUserId": "1000"
}
}
Are there any configuration errors that might cause the Test Suite to fail to send the EXECUTE intent? Or is this a bug?
I am not able to control these devices from Google Assistant directly (from my phone) - I get the error "this device has not been set up yet" but see no options to add it as a controllable device from the Home Control screen in the Assistant app settings.
Thank you for highlighting the issue. I can reproduce it on my side. Can you please open a bug in Public issue tracker for further debugging and share the same information there.
I’m going to follow up with the team and update you through the issue tracker.
I have cloud run services hosting GO OSB application implementing gRpc but exposing the http REST api's via grpc-gateway which uses cloud sql (mysql) as a DB. All the CRUD API's are responding fine except the PATCH one.
It's throwing the below error with http response code 503:
{
"textPayload": "The request failed because either the HTTP response was malformed or connection to the instance had an error.",
"insertId": "6141e984000c63529e7b7afd",
"httpRequest": {
"requestMethod": "PATCH",
"requestUrl": "https://********-********-mr336-qv7hk7cx3a-uc.a.run.app/v2/service_instances/237e80fd-b22e-4df0-b9ed-23c91a4d7f51",
"requestSize": "1102",
"status": 503,
"responseSize": "976",
"userAgent": "PostmanRuntime/7.28.4",
"remoteIp": "********",
"serverIp": "********",
"latency": "0.410343680s",
"protocol": "HTTP/1.1"
},
"resource": {
"type": "cloud_run_revision",
"labels": {
"location": "us-central1",
"revision_name": "********-********-mr336-00001-hop",
"project_id": "********-********-l-app-us-01",
"configuration_name": "********-********-mr336",
"service_name": "********-********-mr336"
}
},
"timestamp": "2021-09-15T12:39:32.811858Z",
"severity": "ERROR",
"labels": {
"instanceId": "00bf4bf02dff6d5f53cff1f1828cafbca265606a996eddff5cb44e3fff674efb77ca51eca7087fb8b8e7acba227b2a3e3e913bdfcc0a487640a2e028"
},
"logName": "projects/********/logs/run.googleapis.com%2Frequests",
"trace": "projects/********/traces/e29e5add9452d171e9eebd26817bb667",
"receiveTimestamp": "2021-09-15T12:39:32.817171397Z"
}
Points to Note :
After every patch request I can see the instance start-up logs, i.e. after the above mentioned logs every time I can see the container entrypoint (server) startup logs (like cold-start).
As soon as server startup is complete, it again throws the same above error in logs.
Important point to note is that I also can't see any logs from my application which suggests PATCH api request is not reaching the container instances running behind the cloud run services.
Also my active instances after cold start goes to ideal and then scales down to 0 with in a 1 min. after the last request hit, but it doesn't seems to create issue for other APIs. This is how it is supposed to work but can't find any lead on what's the issue with PATCH.
This is fixed now !
Facing the due to handling of multiple protocols on the same port and one of the protocol matchers was causing the issue with PATCH API by returning Empty reply from server. So, done changes to the matchers and it worked.
RCA :
Cmux HTTP1Fast Matcher only matches the methods in the HTTP request.
This matcher is very optimistic: if it returns true, it does not mean that the request is a valid HTTP response.
A correct but slower HTTP1 matcher, used "HTTP1" instead which scan the whole request up-to 4096 bytes but its bit slow.
We're using https://github.com/googleapis/google-api-python-client to connect to Gmail which handles the discovery as well. Today we noticed that APIs are not going through in one of the servers and figured out the discovery cache (cached at google-api-python-client-discovery-doc.cache) is invalid and not JSON parseable.
It looks like the discovery schema is incorrectly built or in transit something is lost(how latter can happen, I have no idea)
I've added the partial JSON here, you can see the invalid JSON at line:7 here.
"quotaUser": {
"type": "string",
"description": "Available to use for quota purposes for server-side applications. Can be any arbitrary string assigned to a user, but should not exceed 40 characters.",
"location": "query"
},
"upload_protocol": {
"description": "Upload protocol for media (e.g. \"raw\", \"eapis.com/auth/gmail.settings.sharing": {
"description": "Manage your sensitive mail settings, including who can manage your mail"
},
"https://www.googleapis.com/auth/gmail.modify": {
"description": "View and modify but not delete your email"
},
"https://www.googleapis.com/auth/gmail.metadata": {
"description": "View your email message metadata such as labels and headers, but not the email body"
},
"https://www.googleapis.com/auth/gmail.labels": {
"description": "Manage mailbox labels"
},
"https://www.googleapis.com/auth/gmail.addons.current.message.metadata": {
"description": "View your email message metadata when the add-on is running"
},
"https://www.googleapis.com/auth/gmail.insert": {
"description": "Insert mail into your mailbox"
}
}
}
I've attached the full discovery doc for valid one and invalid one here: https://drive.google.com/drive/folders/12LWm_EKNeWenJWUeIJA8BRDrXjz27OYO?usp=sharing
Do note that when this cache is invalidated, it works fine and the API is fine. The format is slightly different when this happens, so is it possible that Gmail is experimenting with something and this happens sporadically?
The fact that cache invalidation fixes the issue (meaning Python is directly grabbing a copy of the file, not using your cache) likely indicates the corruption is happening in your cached document. Seems like an issue with how it's stored on the filesystem.
Can you ever reproduce the issue if discovery file caching is completely disabled?
I have created one self SSL-Certificate of format i,e demo.ssl.cer.p7b.
Added this certificate in JDK and web browser under trusted certificate storage.
When the application was working on HTTP, I used to receive the request payload in JSON format which was correct.
Now after enabling HTTPS on server side,the request payload format has been changed and it is not in JSON.
Not able to understand the data and also not sure how the message is changed and delivered to the controller. Can anyone please suggest more information on understanding the same.
Note : Posting through AJAX.
Request payload
{
"producerAPI": {
"host": "xx.xx.xxx.xxx",
"port": "84xx",
"context": "iProducer/getDataDB"
},
"consumerAPI": {
"host": "xx.xx.xxx.xxx",
"port": "84xx",
"context": "ConsumerAPI/consumerAPIXml"
},
"dataMapper":{
"inputFormat":"json",
"outputFormat":"xml"
}
}
Once request reaches controller, we are getting below mentioned format
producerAPI%5Bhost%5D=localhost&producerAPI%5Bport%5D=84XX&producerAPI%5Bcontext%5D=iPaaSProducer%2FgetDataFromDB&consumerAPI%5Bhost%5D=xx.xx.xxx.xxx&consumerAPI%5Bport%5D=80XX&consumerAPI%5Bcontext%5D=ConsumerAPI%2FconsumerAPIXml&dataMapper%5BinputFormat%5D=json&dataMapper%5BoutputFormat%5D=xml
This issue got resolved by stringifying request payload.
We are trying to create an approval workflow using Teams, Flow, and Assembla and are running into a bit of trouble.
We have a few of the pieces successfully setup however we are unable to initiate a POST action from a card in Teams.
In teams we can successfully create a card using the incoming webhook connector with this result.
This is created with the following JSON body from a POST action in Flow
{
"##type": "MessageCard",
"##context": "http://schema.org/extensions",
"summary": "This is the summary property",
"themeColor": "f46b42",
"sections": [
{
"startGroup": true,
"title": "**Pending Review**",
"activityTitle": "Ticket Title",
"activitySubtitle": "Requested by: ",
"facts": [
{ "name": "Date submitted:", "value": "06/27/2017, 2:44 PM" },
{ "name": "Details:",
"value": "This ticket is ready for review." }
]
},
{
"potentialAction": [
{
"##type": "HttpPOST",
"name": "Approve",
"target": "ANOTHER-POST-URL-IS-HERE"
},
{
"##type": "HttpPOST",
"name": "Deny",
"target": "ANOTHER-POST-URL-IS-HERE"
}
]
}
]
}
We have another Flow url as the target for both buttons on the card. To test this url we are able to successfully post via POSTMAN and continue the approval workflow.
When clicking the button on the Team card the Flow at the post url is in no way notified at all. No run on Flow is triggered. In teams a very generic "There was a problem submitting your changes. Try again in a minute." error is displayed.
After researching I ran across the connectors.md file on the Microsoft Teams github page and noticed this lovely part of the documentation
It seems odd to me that right below them mentioning that POST actions may not be supported the documentation goes on in length to show examples of using POST and ActionCard actions in a card on teams.
So my question is this, is there any way to get an HttpPOST action to work from a custom card in Teams to a Microsoft Flow POST URL?
Thanks!
Update:
Upon further testing we have determined that HttpPOST actions
work with just about any post url we can come up with except
Microsoft Flow Request URLs. They are exceptionally long urls so maybe
that has something to do with it?
Here's an example Flow request url.
https://prod-43.westus.logic.azure.com:443/workflows/f86b928acd3d4ecab849f677974f7816/triggers/manual/paths/invoke?api-version=2016-06-01&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig=ZBxr5GFKQhMp4JXWGmec_L6aqgcaqvCOKUWOf2li-xQ
When running teams in a web browser we are able to see the request
first posts to a api.teams.skype.com url and returns a generic
"ProviderError". Other non-flow urls also do the same but return
success.
This was a head-scratcher for us - as you surmised, this should have worked. The Teams, Flow, and Outlook teams troubleshooted this today and found out what was going on.
The URL you are posting to, https://prod-43.westus.logic.azure.com[...] has an embedded bearer token (the value of the sig parameter in the URL). When you POST to that URL via CURL, Fiddler, Postman, etc. it works because that token is present.
However, when you click on a HttpPOST button in an actionable message, Outlook adds its own JWT token in the HTTP header, meaning that the HTTP POST has both a sig= bearer token in the URL and a JWT token in the HTTP header. Flow detects this and rejects the HTTP POST as invalid (while we don't currently support JWT tokens, we plan to, and treat this case as invalid to maintain forward compatibility).
This use case will work in the future. In the meantime, one workaround to try would be to have the actionable message buttons POST to your endpoints, e.g. https://yoursite.com/accept and https://yoursite.com/deny (validating the JWT as much as you like) and have these endpoints POST to Flow directly without the JWT.
Please let us know if that works.
BTW, the text you found is a documentation bug that has since been fixed:
Sorry for the confusion.