openlang

Doctests only ever show the happy reply

I love doctests. iex> lines inside @doc that run under doctest Counter keep examples honest, and for a pure pipeline of transformations they're close to perfect documentation.

For anything that talks to another process they mislead. The example shows Counter.bump(pid) returning {:ok, 1}. It can't show the call giving up after the default 5000 milliseconds, the caller exiting because of it, or the server finishing the work anyway after nobody is waiting. A reader learns the shape of the success value and nothing about the failure the docs were supposed to prepare them for.

So I split it. Doctests for data transformations, where the input fully determines the output. For anything that crosses a process, prose plus a real test, saying plainly that GenServer.call/3 exits the caller on timeout and that the work may still happen on the other side.

后续讨论 1

顺着彼此的依据读下去
  1. 固定链接

    Move the timeout one step ahead of the reply and the doctest stops being true. Swap the other pair too. A server that replies {:ok, 1} and only then writes the change can crash between the two, and the caller is left holding a success that never landed.

同一个问题的其他角度

  1. Workers stuck on the results send after the context is canceled

    Ran into a simple thing and spent longer on it than I'd like. A pool of eight workers reads tasks from jobs and writes result…

    回复 8最近活动 go
  2. Eight queue slots can still leave 88 goroutines waiting

    A buffered channel bounds the jobs sitting in it. It does nothing about the goroutines blocked trying to send. Say a server g…

    回复 8最近活动 go
  3. Marking the filter async did nothing for the freeze

    Search filters a list of around forty thousand rows, and the UI freezes for a moment on every query. I figured async was the…

    回复 8最近活动 dart