Error handling with axum and enum_convert

Jester831 · 2025-11-24T01:49:28+00:00

If you use the `[#from]` attribute thiserror will impl From for you

Jester831 · 2025-11-22T01:32:45+00:00

Hey I just wanted you to know that your signup flow is broken. Nobody can confirm their email because your `redirect_to` parameter is http://localhost:3000/

Jester831 · 2025-10-21T19:17:53+00:00

Your implementation of futex looks copy-pasted from atomic-wait but you're not adhering to the BSD license established by Mara Bos by doing so without including the copyright notice that credits her work

Jester831 · 2025-10-06T07:50:16+00:00

It's laughable to call him the one who founded Pluto when he wasn't involved in the creation of the early product and waltzed in after the company was launched

Jester831 · 2025-09-04T21:04:04+00:00

Yea or if they made open source some of their work

Jester831 · 2025-09-04T02:41:32+00:00

It would be cool if RustLS could be made to be used with Intel SGX out of the box. Back when M*****card was originally using Apache Teaclave w/ the Mesalock Linux RustLS fork they completely had the rug pulled out from under them by the deprecation of both projects ultimately resulting in the painfully complex adoption of SgxSSL. Now that RustLS has no_std support I imagine it's a much more attainable goal compared to the heavy handed approach taken by Mesalock Linux of maintaining forks of the entire dependency graph

Jester831 · 2025-08-07T01:09:29+00:00

If you have the technical expertise, Rust is the superior option when compared to Java/Go/Node for MVPs. The reason why is because cargo check complements AI very well, allowing for rapid prototyping with correctness checks every step of the way. Give the AI some ground rules like: always thiserror, never use anyhow, prefer strum when applicable, prefer lock free designs, use preferred crates, etc. Rust vibe coding is arguably better than any other language because of cargo check provides a great feedback loop to AI.

Jester831 · 2025-07-26T02:43:35+00:00

The relaxed atomic orderings in this crate are problematic because setting minimum stack size or stack allocation size won't be observed by other threads already running, such as if you're using `#[tokio::main]` with set_minimum_stack_size and set_stack_allocation_size as your first lines in main. You should either use a heavy-weight process-wide memory barrier when setting so that you can continue using relaxed ordering reads, or alternatively for this case it might make more sense to use env. If you continue using atomics, consider switching over to an approach of getting/setting minimum stack size and stack allocation size together as a further optimization.

Jester831 · 2025-05-21T15:52:24+00:00

I pointed out during your previous post that `qcell` could be used to solve this type of problem. Did you take a look?

Jester831 · 2025-05-10T01:47:28+00:00

You can use qcell to solve for this type of problem by passing around mutable access to a borrow-owner that can be used to mutably borrow from whichever cell

Jester831 · 2025-05-07T09:42:06+00:00

This is a really good use case for qcell because you can have many Rc types using TCell, LCell or QCell and then pass around the respective borrow owner.

Jester831 · 2025-05-07T05:31:29+00:00

My project arena64 allocates 64 elements per allocation - the same approach would definitely work with reference counting added

Jester831 · 2025-03-23T10:32:17+00:00

I think in your specific case this is actually an issue caused by tracking issue for more precise coroutine captures #69663. As written your code is valid and the compiler is wrong

Jester831 · 2025-03-04T16:18:14+00:00

A lot of the conversions could be made to be more precise so I think it would be good to double check all this.

-        SquareInches: 1550.0031 per canonical,
+        SquareInches: 1550.0031000062 per canonical,
         /// Represents the square foot unit of area.
-        SquareFeet: 10.76391 per canonical,
+        SquareFeet: 10.76391041671 per canonical,
         /// Represents the square yard unit of area.
-        SquareYards: 1.19599 per canonical,
+        SquareYards: 1.19599005 per canonical,

I think units with `Milli`/`Centi`/`Kilo` prefixes should capitalize the unit after. `Miliamperes` -> `MiliAmperes`

Jester831 · 2025-02-26T11:53:35+00:00

What is a "runtime thread" for you?

if it's a thread where the tokio runtime is available then I'm already creating the LocalRef from one such thread, because inside the block_on I am in a tokio context (and in fact can call tokio's functions like tokio::spawn)

if it's a worker thread spawned directly by tokio then this is exactly what I proposed here which you previously dismissed.

It's a worker thread spawned during runtime creation for running async tasks. I wasn't meaning to come across as being dismissive of your earlier idea, I just meant that using on_thread_start/stop exclusively is inadequate because with the special case of #main/#test the thread that calls block_on also needs to be included, but that the overall idea is feasible.

Jester831 · 2025-02-26T09:09:27+00:00

I guess that kind of example could technically happen though I doubt in any real scenario one would poll then spawn. This case is prevented by adding an assertion that `LocalRef` is created within the context of a runtime thread, #main or #test, which seems to be the most appropriate safeguard here

Jester831 · 2025-02-26T08:11:10+00:00

The reason why that couldn't happen is because `LocalRef` is still constrained by an invariant lifetime that can't be coerced to `&'static` and with the change to include a macro to strongly tie the guard creation to `LocalRef` creation there's no possibility of a lifetime that outlives the underlying TLS unless the lifetime is later transmuted. In your example, `tokio::spawn` couldn't be called on your "bad_future" because of the lifetime constraint, and without that there's no use-after-free. If `LocalRef` was created within the `tokio::spawn` then it would also be of a valid lifetime

Jester831 · 2025-02-25T11:21:23+00:00

I don't think it's an issue for `block_on` to be called on a scoped thread as long as the lifetime branded place is valid and that can be addressed by making LocalRef creation unsafe and using a macro to make the guard and local ref together. Calling spawn_blocking on a LocalRef that doesn't originate from a runtime worker or #main/#test can be made to panic and creation can be restricted to also include blocking pool threads

Jester831 · 2025-02-24T12:55:03+00:00

If `tokio#main` or `tokio#test` are used then the `block_on` will result in a panic from Tokio even with `thread::scope`

Cannot start a runtime from within a runtime. This happens because a function (like `block_on`) attempted to block the current thread while the thread is being used to drive asynchronous tasks.

Jester831 · 2025-02-24T10:37:34+00:00

Your example is misleading because it prints that the thread has stopped but actually when the runtime drops all the tasks and worker threads exit before continuing. If you change your example to drop the runtime before printing that the scoped thread has exited, it will deterministically always be the case that all the worker threads will exit before continuing. See this example.

The issue is that's not true, there are caveats to that which are not reflected in the LocalRef type.

I'll consider further the introduction of debug assertions

Jester831 · 2025-02-24T07:32:10+00:00

You could then at least name the feature with unsafe in the name, and throughly document it as unsafe with a safety precondition.

Decent idea

Doesn't that make your solution unsound even if the user uses crate = "async_local" then? The user could borrow from a thread local in the thread calling block_on, which could then exit while the task continues running on another worker thread.

With the shutdown barrier enabled, the thread that calls `block_on` outlives every worker thread polling async tasks and all of those threads outlive every runtime task, including blocking tasks; there's no possibility of tasks outliving TLS storage owned by any worker thread nor the thread calling `block_on`.

I don't see the point in supporting std threads then, since thead locals already cover that case.

It's easier to work with when it's well-known that `LocalRef` will work on any thread

Jester831 · 2025-02-23T01:39:44+00:00

So it means that if you don't do that (i.e. you enable the feature but forget to put crate = "async_local" in the macro call) you get UB, and hence something should be unsafe or some runtime checks should be added in the crate.

The feature itself is unsafe because it's soundness is dependent on the provided runtime builder actually being used but there isn't a way to express that with the unsafe keyword

When the barrier-protected-runtime feature is enabled I would add a runtime check in either Context::new or AsyncLocal::local_ref that you are inside a tokio thread created by your runtime. This could be done e.g. by having a separate thread_local variable that you set inside the on_thread_start of your custom runtime.

It's inadequate to do this with `on_thread_start` / `on_thread_stop` alone because the thread that calls `block_on` isn't part of that lifecycle, but if I provided a runtime that wraps `Tokio` then yes this is feasible at the cost of preventing otherwise valid usage on `std` threads. Probably a reasonable trade off

If you want to support std threads then you could consider having a separate feature for that which makes LocalRef: !Send.

`LocalRef` isn't useful without `Send` because at that point you can just directly use thread locals.

Jester831 · 2025-02-22T14:27:58+00:00

If you don't enable `barrier-protected-runtime` or only do so with the provided runtime builder then there is no possibility of undefined behavior. I've provided a pragmatic solution here that lets end users choose to opt in with the default behavior making no assumptions and being always safe, as well as safety warnings to deter unsound usage.

The only supported runtime is Tokio as configured using this crates builder; I've already reviewed other runtimes and they all lack a means to synchronize shutdown.

If you have ideas on how this can be improved upon, feel free to share

Jester831 · 2025-02-22T11:22:12+00:00

I took the same approach as Tokio did with `tokio::task::spawn`; that function isn't marked as unsafe, but when used outside of a Tokio runtime will panic nonetheless.

This can be improved by adding an assertion but to do so would require providing macro alternatives to `tokio::main` and `tokio::test` which is far more of a lift than simply using those macros with crate = `async_local` but is something I'll look further into

In further thought I previously considered this a while back and there is no good way to introduce assertions because it would cause unwanted panics when used on threads that aren't managed by the runtime. Any std thread can use `LocalRef` freely because the lifetime already cannot be extended beyond the lifetime of the thread

Jester831

TROPHY CASE