We should make sure first, that the Haskell updates from upstream are really applied to
our build schedule in exactly that order (as I fear order of rebuilds matters a lot).

As an easy fix in the past I was successful by selectively building parts of the failed Haskell module, but I easily ended up in dependency circles (where this library hash doesn't come in
handy at all!)

As I last resort I can think of a script checking the build error logs and trying to
guess package names which needs to be rebuilt:

Configuring attoparsec-0.13.2.4...
Error:
    The following packages are broken because other packages they depend on are missing. These broken packages must be rebuilt before they can be used.
installed package tasty-1.3.1 is broken due to missing package ansi-terminal-0.11-2SXi8ZhU18i2uWLidRUotS, async-2.2.2-K8T9LglWxlG5HgD5vvGjbo, optparse-applicative-0.16.1.0-JDPEASK1GJS1Nsq2qjjZCq
installed package tasty-quickcheck-0.10.1.2 is broken due to missing package QuickCheck-2.14.2-io0WylueSG4seqSTUQCKM, optparse-applicative-0.16.1.0-JDPEASK1GJS1Nsq2qjjZCq, random-1.2.0-1bl1BCDTJTv7mTz0mMuFeh

So in this example this means haskell-tasty needs a rebuild against new versions of
haskell-async, haskell-optparse-applicative and tasty-quickcheck one against haskell
quickcheck, haskell-optparse-applicative and haskell-random.

I also fear we cannot simply drop Haskell easilily for things like 'pandoc' or
'shellcheck'.

"As I last resort I can think of a script checking the build error logs and trying to
guess package names which needs to be rebuilt:"

We do that already: the buildmaster does reschedule the respective packages upon report of error. However, as you noted: Dependency cycles make this approach fail, too, because then, everything depending on haskell-tasty or haskell-tasty-quickchek which was already built needs to be rebuilt, too …

check the build scripts starting from:

https://git.archlinux32.org/builder/tree/bin/return-assignment#n291

maybe the regex does not work anymore or something like that …

nope, the regex looks good.

I had a (brief) look into the haskell mess and the problem seems to be, that a few haskell-* packages genuinely fail (e.g. haskell-tasty) on 32 bit.

The buildmaster ignores failed packages after some time (a few days, I think). The reasoning behind that is, that for "normal" packages (like libraries), this will not block all dependent packages (imagine libfoo and package bar, depending on libfoo. Both get an update, but libfoo fails to build. At some point, we want to have the new bar even if it's compiled against the old libfoo - this is especially true, if "libfoo" is actually just some boring makedependency, like git, or some doctohtml or whatnotelse). Unfortunately, with haskell-* this won't work, because the dependency *must* be rebuilt to update the hash (e.g. makedepends pandoc will not work in the old version).

These haskell-* packages have build errors which are not "due to haskell itself":

haskell-generic-data
haskell-libbf
haskell-profunctors
haskell-quickcheck-classes-base
haskell-rank2classes
haskell-semigroupoids
haskell-tasty
haskell-th-lift-instances
haskell-tidal

Now ghc itself fails:

"inplace/bin/mkdirhier" libraries/ghc-prim/dist-install/doc/html/ghc-prim//.
"inplace/bin/mkdirhier" libraries/ghc-prim/dist-install/build/autogen/GHC//.
"inplace/bin/genprimopcode" --make-haskell-source < compiler/stage1/build/primops.txt > libraries/ghc-prim/dist-install/build/autogen/GHC/Prim.hs
"inplace/bin/ghc-cabal" hscolour libraries/ghc-prim dist-install
ghc-cabal: The program 'hscolour' version >=1.8 is required but the version of
/usr/bin/HsColour could not be determined.
make[1]: *** [libraries/ghc-prim/ghc.mk:4: libraries/ghc-prim/dist-install/doc/html/ghc-prim/ghc-prim.haddock] Error 1
make: *** [Makefile:128: all] Error 2
==> ERROR: A failure occurred in build().
    Aborting...

and again on i686:

1. > Compressing package…

zstd: error 11 : Allocation error : not enough memory