zhangzhen
I use phoenix/elixir to write a mini-system that monitors the status of tasks that Nextflow (a workflow engine) starts. I called the system br-tower. Nextflow calls a web callback, i.e. webhook, I implemented when the state of a job changes. Most of these http requests can be handled by br-tower, but a few requests cannot. I use wireshark to capture the tcp packages Nextflow sends to br-tower, in order to find out whether such requests have any json payload or not. Surprisingly, they all have json payload. In the figure below, such requests are framed in red. Besides, http get requests in-between don’t get any response back. In the console where mix phx.server ran, only [info] POST /webhooks/nextflow was printed out, and no Parameters part follows. It is very weird. I will be very grateful, if someone could help me to solve this problem.
Trending in Questions
Other Trending Topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixirconf-us
- #ai
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming












Showing Posts 1 to 10- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
derek-zhou
What you are doing is nothing out of ordinary. However, you may want to post more details, like console prints, router code, etc so other people can help you.
One thing I can think of is if you are posting from another origin, you need to make sure CSRF is not in your way. In any event, there should be error message in the console; no requests should be silently dropped.
zhangzhen
@derek-zhou, Thank you!
the code for the router is listed below:
The screenshoot for the console is pasted below. Please ignore the text labelled on the figure because I thought there was no payload, but in reality payload was there.
derek-zhou
So what is the problem? you did receive payload.
lud
Do you have an unit test that works all the times, or that fails too?
Check the docs to implement such a test if you don’t already know how.
zhangzhen
The problem is http requests with payload were rejected silently by Plug and didn’t reach for the corresponding controller action.
I don’t have any unit test for this case till now.
when the weird case happened, the v2ray service (sort of a proxy) was on. I suspect that the v2ray service is most likely to be the culprit. I will report back if I can determine what the cause is.
derek-zhou
In your log after the first
POST /webhooks/next/flow, there is aSent 200 in 1 msso at least it worked for once. If subsequent requests are not handled, it is most likely a bug in your program so your controller hangs.If Plug decided to reject any request for whatever reason, ther will be print in the console.
zhangzhen
The screenshot shows only a very tiny part of log info. Post requests after the part worked normally. In addition, a few GET /batches/[:batch_id] didn’t work either. I think that this has nothing to do with the code for the controller action.
The following code snippet is about the controller and the related parser. I cannot find where the bug lies indeed.
derek-zhou
Other people cannot help you debug your code unless you can make a minimum reproducible case and put it on github.
Elixir gives you many tools to debug; you have a console, a remote iex shell, even a live dashboard. Also you will need to have some faith in Phoenix; it is much more likely the bug is in your side.
zhangzhen
In my log, [info] POST /webhooks/nextflow was output by the Plug.Logger, and [debug] Processing with BrTowerWebuiWeb.WebhookController.nextflow/2 … was output by the phoenix_router_dispatch_start in the Phoenix.Logger. phoenix_router_dispatch_start is installed as the event handler for [:phoenix, :router_dispatch, :start]:
https://github.com/phoenixframework/phoenix/blob/60da3f0dc01b7e0eae0e5bd608431ead953ded5d/lib/phoenix/logger.ex#L128
This means dispatching a request to the corresponding controller action was not started because the related debug line was missing in my log, so I can conclude that this case is not caused by the bug that perhaps exists from my controller part.
Sorry, I cannot put my code on github because of the policy of our company, but i can give you the architectural design which is shown in the following figure:
voltone
Or, alternatively, the function you attached to
:phoenix_router_dispatch_starthas a problem and Telemetry removed it after that first invocation:I would start by putting some debug logs in the controller itself; Telemetry is perhaps not the best tool to rely on for debugging.