Increase the webhook timeout period, or allow users to set their own timeout period.

Issue #12211 wontfix
Gary Sackett staff created an issue

The current timeout of 10 seconds isn't long enough for very large repos. For instance, those users who are using bitbucket to deploy files to websites and need it to accurately determine if a timeout has actually occurred.

Comments (13)

  1. Nathan Shubert-Harbison

    I'm running into this issue myself on a repo with 2 submodules I also want to update on commit.

  2. Jiří Nápravník

    It is quite neccesary. I build satis, only partial (for one module), and it is almost always timeouted.

    At least it would be good also turn off automatic retry. Because it timeouts, but script is still running and is succesful, but webhooks are still auto-retrys.

  3. Gonzalo Arce

    hey, yes please, im being unable to use the new webhooks because of this, my proyects are auto retrying its deploys even though they finished fine due to the timeout limit.

  4. Christoffer Ejerskov Pedersen

    I have the same issue. It's almost useless to use the webhooks because of the timeout limit.
    I've got a failed POST now, so how should I progress from here?
    Should I revert the commit and check-in fewer files at a time? Or manually upload the files through my FTP?
    Either way is contradicting the very reasons I started using bitbucket in the first place.
    It disrupts your workflow and a proper CI pipeline is not possible.

  5. Tom Somerville

    Yeah I have the same problem, it does run my deployment, but because it times out it will run it again, which basically means it gets deployed 3 times

  6. Lars Støttrup Nielsen

    Potential PHP solution for fastcgi users.
    Insert at "fastcgi_finish_request();" right after receiving the webhook, this will flush and return to the client but continue processing.

    Our timeouts have disappeared because of this.

  7. Nicholas Bowers

    Hey all, I've gone back and forth on this issue for deployment use-cases. At first, I was just as annoyed with this implementation as you are; after doing more research, however, I've had a change of heart. Deployment is a very resource intensive process depending on your environment and hardware - short of having an absurdly long timeout, there's not much that can be changed here (not to mention the fact that there would be no way for BitBucket to know if your script is still running or if there was ACTUALLY a problem that a timeout would have circumvented by processing a re-request). It's actually pretty impolite to keep their webhook waiting on a response while we go through our entire deployment processes.

    The correct way to handle this is to queue the deployment. At the simplest level, you can have the webhook hit a script that creates a temporary "flag" file. After creation, the webhook gets its response and doesn't try calling again. Meanwhile, have something similar to a cron job running on your environment every minute or so that checks for the existence of this flag. If the flag exists, delete it and then process your deployment. If there are any errors during deployment, you should be able to deal with those with proper error handling implemented.

    This is better all around design than asking BitBucket to arbitrarily increase their timeouts for something that varies wildly across different environments.

  8. Kaleb Elwert

    We don't plan on changing our current behavior in regards to webhook timeouts. Waiting on deployments to finish is not something we had in mind when designing this feature and it's not very reasonable to support.

    If you have a job that will take a long time, please consider handling the payload and using that to queue something. 10 seconds should be more than enough for that.

  9. Cristian Lisneanu

    How do you feel when you build documentation at least twice on every single push you make? Let me choose my webhook timeout!

  10. Log in to comment