profile
viewpoint
Victor Repkow vicrep @dialoguemd Montreal Staff Software Engineer @dialoguemd

vicrep/McHacks-FFS 2

A mobile application which allows for second hand item exchange / sale around university campuses.

vicrep/551-P1 0

Script used for COMP551 F'17 project

vicrep/ant-design 0

🌈 A UI Design Language

vicrep/COMP206-A4 0

Final Assignment for COMP 206 - Intro to Software Systems (McGill, W'16)

vicrep/conventionalcommits.org 0

The conventional commits specification

vicrep/cypress-test-tiny 0

Tiny Cypress E2E test case

vicrep/ECSE321-Team7-SoccerScoring 0

ECSE321 Team 7 Group Project

vicrep/ECSE428---A-Mobile-Postal-Rate-Calculator 0

Mobile app which calculates postage rates in Canada, as a part of McGill's ECSE428 Assignment B

vicrep/Java8-Streams-HammingNumbers 0

Finding hamming numbers using a basic implementation of haskell/scheme-style streams using Java 8's new Functional / Predicate interfaces

startedpetyosi/react-virtuoso

started time in a month

pull request commentdialoguemd/fastapi-sqla

fix: other middlewares don't run when there's an exception in fastapi-sqla context manager

@hadrien I guess there's two facets to this.

One, that the auto-commit is really painful when it fails, as the user and app gets no feedback. I still think it should be opt-in-able, it's so far brought me more pain than benefit of saving you from writing session.commit(). But I digress, this is about getting feedback from the client when a request fails due to some DB (or even non-db) operation issue.

Secondly, we should be returning properly formed 500 responses in this middleware. The reason is that if you look at Starlette's default middleware stack, it has a inner-level ExceptionMiddleware who's job is to convert a HttpException to a proper response with status code. However, custom middlewares will always run after this middleware (since it's the innermost one), and therefore won't benefit from the conversion of HttpException that would occur if the error was in-app.

Can I therefore suggest then that we make an addition to this middleware so that it returns properly formed 500 responses, instead of re-raising an error? I believe that the logging middleware should already be aware / be able to understand 500 responses and log those appropriately, and I don't think that those kind of errors are "unexpected" from the PoV of this middleware, and therefore should not be raising exceptions in the middleware stack.

vicrep

comment created time in 3 months

pull request commentdialoguemd/fastapi-sqla

fix: other middlewares don't run when there's an exception in fastapi-sqla context manager

Hello @hadrien , should we jump back onto this PR and try get it merged? It's a big QoL improvement when dealing with CORS apps, where you effectively can't get any status code on uncaught failures otherwise.

vicrep

comment created time in 3 months

more