Sepolia Faucet not working since last 3 or 4 days

[deepmineblocks]

Faucet not working since last 3 or 4 days.

I regularly use this faucet to get testnet tokens but not working since last 3 or 4 days. After clicking the Start Mining button below error was thrown

[pk910]

Heya @deepmineblocks
Thanks for reporting, I've checked the sepolia faucet a moment ago and it seems to work fine..
But yea, something looks clearly broken on your side.

Can you check the developer console of your browser and find the failing call?
You can do it like this:

• Go to the faucet site
• Open the developer console (It's usually opened with F12 or via the browser menu)
• Try starting the faucet session (enter address, solve captcha & hit the start button)
• Select the network tab within the developer console and filter for "startSession":
  

It looks like this call returns a HTTP error for you, which I'm not sure where it's coming from :D
Need to see the full error to see what's going on

[deepmineblocks]

Below is the response

I didn't understand why it is saying "504 Gateway Time-out".

[deepmineblocks]

Any update on this ?

Its still not working for me

[ran-noumena]

I'm getting this error response as described below once the startSession is falling:

<title>504 Gateway Time-out</title>

504 Gateway Time-out

---

nginx/1.14.2

[deepmineblocks]

I'm getting this error response as described below once the startSession is falling:

<title>504 Gateway Time-out</title> # 504 Gateway Time-out nginx/1.14.2

Same with me

[pk910]

I can see the failed requests on server side, it actually affects 5-6 sessions only every day, but seems to be persistent for single users...
It's really weird and I'm not sure where it's coming from.

I've enabled some debug output on the sepolia instance now.
Can one of you please try to re-trigger the issue?
@deepmineblocks @ran-noumena

[ran-noumena]

@pk910, it works again for me :)
the startSession response:
{"session":"387bbe9b-c482-4141-a6a9-798c4b8df868","status":"running","start":1724917433,"tasks":[{"module":"pow","name":"mining","timeout":1724960634}],"balance":"0","target":"0x2e8....","modules":{"pow":{"lastNonce":0,"preImage":"/WkU5d9LP94=","shareCount":0},"passport":{"nonce":1,"score":16.042,"factor":1.3}}}

[deepmineblocks]

Again started working

Thanks @pk910

startSession Response

{
    "session": "135234e0-7536-4188-b584-5228b07153a7",
    "status": "running",
    "start": 1724918974,
    "tasks": [
        {
            "module": "pow",
            "name": "mining",
            "timeout": 1724962174
        }
    ],
    "balance": "0",
    "target": "0x818549Bd829b8F9Aa13Dc0dE9d3242Ee631a5438",
    "modules": {
        "pow": {
            "lastNonce": 0,
            "preImage": "BmkawJ7hlzU=",
            "shareCount": 0
        },
        "passport": {
            "nonce": 1,
            "score": 34.342999999999996,
            "factor": 2.6
        }
    }
}

[pk910]

Yea, I've restarted the process to enable the debug output :/
That made the problem disappear for you guys, but didn't actually solve anything.

I think it might be related to the passport or ipinfo cache. Both modules cache promises of active requests (ip or passport lookups).
This issue feels like there's a never resolving promise in that cache, so everytime someone retries using the faucet with the same IP or address with such a bad cache entry will end up with a timeout.

I'm rreopening the issue as the underlying problem is not solved.
Debug output is still active, so, if anyone runs into a similar problem, please respond here soonish.

[deepmineblocks]

@pk910

You did 3 commits, so I think the issue is resolved and I closed the issue 😊.

Good to know about some underlying things.

If you need any assistance/debug logs etc feel free to post here...

[pk910]

that's exactly the problem :D
I did not change anything that might had an effect on that issue.
I've even reverted these commits again as the additional debug output heavily spams the logs..

However, to run the new code I've restarted the process, which kind of solved the problem for you two.
The underlying issue that caused the problem is still there :D

[Leooehh]

@pk910
I had a user who was facing this issue which odd enough they could access with no issues using a vpn.. My instance doesn't have passport enabled, I only have IP, Mainnet and captcha enabled.
I hope this helps, cheers.

[pk910]

The issue was triggered again twice on the sepolia instance in the last 3 days.

~/sepolia-faucet$ cat faucet-events.log | grep "ed5cf092-5d44-4de5-825c-05cd033aee74"
2024-09-10 03:17:09  INFO     sessionStart ed5cf092-5d44-4de5-825c-05cd033aee74  start: local 0
2024-09-10 03:17:09  INFO     sessionStart ed5cf092-5d44-4de5-825c-05cd033aee74  nop: local 0
2024-09-10 03:17:09  INFO     sessionStart ed5cf092-5d44-4de5-825c-05cd033aee74  start: module captchacaptcha check
2024-09-10 03:17:10  INFO     sessionStart ed5cf092-5d44-4de5-825c-05cd033aee74  end: module captchacaptcha check
2024-09-10 03:17:10  INFO     sessionStart ed5cf092-5d44-4de5-825c-05cd033aee74  start: module ensnameresolve ens name
2024-09-10 03:17:10  INFO     sessionStart ed5cf092-5d44-4de5-825c-05cd033aee74  end: module ensnameresolve ens name
2024-09-10 03:17:10  INFO     sessionStart ed5cf092-5d44-4de5-825c-05cd033aee74  start: local 1
2024-09-10 03:17:10  INFO     sessionStart ed5cf092-5d44-4de5-825c-05cd033aee74  nop: local 1
2024-09-10 03:17:10  INFO     sessionStart ed5cf092-5d44-4de5-825c-05cd033aee74  start: module passportpassport

Looks like the problem is coming from the passport module, the execution seems getting stuck in there.
It's a bit strange as the http request to the passport api is the only thing that could block the execution there.

Might be reasonable to introduce a generic timeout for all types of http requests in the faucet, just that such issues will not block forever