Reputation: 81
I've written code for money for 20+ years, I have no excuse for this question though.
And oh boy have I googled it. I know that there are many semi-identical questions here, and I think I have read all of the responses, and tried all of the patterns suggested. Many of the questions are not particularly well articulated, and my case seems a little paradoxical (all parts work in isolation). Please bear with me and I will do my best.
Using svelte-kit on the front, and fastapi on the back.
First, below is my "Buttons.svelte" component, copied verbatim in its entirety.
<script lang="javascript">
async function worksJustFine() {
fetch("https://jsonplaceholder.typicode.com/todos")
.then(response => {
console.log(" response", response)
console.log(" r.json() >", response.clone().json())
response.json()
.then(json => {
console.log("json", json)
})
.catch(error => console.log(error))
})
}
async function doesNotWork() {
fetch(`http://localhost:8000/api/test_url?test_param=1`)
.then(response => {
console.log(" response", response)
console.log(" r.json() >", response.clone().json())
response.json()
.then(json => {
console.log("json", json)
})
.catch(error => console.log(error))
})
}
</script>
<buttons>
<button class="btn btn-outline-primary btn-lg" on:click={worksJustFine}>OK</button>
<button class="btn btn-outline-primary btn-lg" on:click={doesNotWork}>NOT OK</button>
</buttons>
<style lang="scss">
</style>
Second, below is the route/view:
@router.get("/api/test_url")
async def test_url(test_param: str):
try:
print(f"test_param: {test_param}")
return {"success": True, "message": "Message", "hooray": True}
except Exception as e:
print(repr(e))
return {"success": False, "message": repr(e), "": True}
The problem manifests like this:
The "NOT OK" button initiates a request which never returns, and the network panel shows only the standard pebkac "(pending)" request, seemingly forever. This is true for Chromium and Chrome, though both GET requests above DO work from Firefox (latest and dev).
The fastAPI URL works perfectly from curl, from insomnia, and from a direct request from the browser in a new tab, using chrome-stable, chromium and Firefox.
If I use a POST request (which is my goal), then it does not work from any browser, at all, ever. Pending, forever. The POST does however work fine when fired from curl, postman etc.
Sometimes I click it and walk away. Rarely, after an unspecified time (half hour, hour?) I return - and find that it DID in fact, work - the request went through, the side effects are obvious. I think this has happened in total, twice over three days of struggle.
It isn't CORS. If I disable the code below, it becomes a CORS issue, but with this code it seems clear. Also, as above, it works fine from FF, who presumably respects CORS too.
app = FastAPI()
app.add_middleware(CORSMiddleware,
allow_origins=["http://localhost:3000"],
allow_credentials=True,
allow_methods=["*"],
allow_headers=["*"])
app.include_router(router)
None of my browsers have any addons or adblockers installed. In my main browser (qtwebengine/qutebrowser) I have a single greasemonkey script to fast-forward youtube ads, and a couple of user-css files.
One common thread among the posts and articles I have read, is that the situation can be different depending on whether or not the debug tools panel is open. In my case, this does not make any difference at all to the situation.
Everything is running on localhost - there are no VMs, no containers... just me and localhost.
Due to the fact that worksJustFine
works just fine, it does not appear to be a svelte/javascript issue.
Due to the fact that test_url
works fine (as POST or GET) from every source other than the fetch API, it does not appear to be a fastAPI issue.
What am I missing? What further information can I provide?
insomnia request, fastapi has not been restarted, chromium request is still pending
Upvotes: 5
Views: 1019
Reputation: 81
Thank you for taking time to read and comment here. I have overcome the issue, although I am not purified of residual confusion.
I was unware that there was a limit on SSE connections - this is hard-capped at 6 in Chromium (firefox also claims that this is the case, and both are flagged wontfix).
I was using exactly 6 SSE connections for different streaming datapoints.
I disabled all SSE endpoints, and GET/POST worked perfectly. I then incrementally re-enabled ALL the SSE endpoints....
Now, the system is precisely unchanged from its state when I asked my question above! However, the GET request works from Chrome and Chromium, and the POST request works from all browsers.
I understand the source of the error, and I've earmarked SSE as "crap to be replaced by websockets on sight".
Thanks again for taking time to talk to me.
"I wish I could just hug you all... but I'm not gonna"
Upvotes: 3