Feature suggestion: Unwrap ActiveJob wrapped Job names in the WebUI

[ibrahima]

Hi! Had another suggestion - this is not super important, but it would be nice if ActiveJob wrapped jobs showed up with their actual job class rather than ActiveJob::QueueAdapters::FaktoryAdapter::JobWrapper in the Web UI. It would be handy when glancing at the UI to see what jobs are coming through the system, especially if you use a lot of ActiveJobs with Faktory.

Edit: I pretty much don't know Go (I skimmed a few chapters of "The Go Programming Language" once) but I started taking a stab at it here:

https://github.com/contribsys/faktory/compare/main...ibrahima:faktory:unwrap-activejob-class-webui

Need to figure out how to test my changes though. Hmm. When I run make dimg and then try to use that image in my local docker-compose dev environment, it doesn't start. But then I checked out main and ran make dimg and tried to run the Docker image that produced, and that also didn't start. So I'm not sure what the issue is...

[mperham]

Yep, your code isn't quite industrial strength (typecasting is dangerous and should always be checked) but that's exactly the right path. Here's Sidekiq's code which handles several edge cases and Rails versions:

https://github.com/sidekiq/sidekiq/blob/73c150d0430a8394cadb5cd49218895b113613a0/lib/sidekiq/api.rb#L374

Send me a PR if you get something you like, here's some test code:

https://github.com/sidekiq/sidekiq/blob/73c150d0430a8394cadb5cd49218895b113613a0/test/api_test.rb#L283

[ibrahima]

Ah great thanks, that's really helpful!

[ibrahima]

One thing that's kinda weird though - I can't seem to run the Faktory Docker images built by make dimg (whether on main or on my branch). It does seem to produce binaries that run on my host in tmp/linux/amd64, but inside the Docker image if I try to run the faktory binary I get an error code 127.

$ docker run --rm -it contribsys/faktory:latest sh
/ # ./faktory 
/ # echo $?
127

I tried gdb... but hm, that doesn't seem to help. (They say to use something called delve but I haven't figured out how to install that in the Docker container unfortunately.)

Reading symbols from ./faktory...
(No debugging symbols found in ./faktory)
(gdb) r
Starting program: /faktory 
warning: Error disabling address space randomization: Operation not permitted
[Inferior 1 (process 22) exited with code 0177]
(gdb) bt
No stack.

Wonder if it's an Ubuntu vs Alpine issue? Or maybe my compiler versions? I know static builds are supposed to be a big selling point of golang so I'm not sure what's going wrong here...

Here's my versions of various things, in case it helps:

$ go version
go version go1.18.1 linux/amd64

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 22.04.3 LTS
Release:    22.04
Codename:   jammy

$ uname -a
Linux zen3 6.2.0-39-generic #40~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Thu Nov 16 10:53:04 UTC 2 x86_64 x86_64 x86_64 GNU/Linux

$ upx --version
upx 4.2.1
NRV data compression library 0.84
UCL data compression library 1.03
zlib data compression library 1.3.0.1-motley
LZMA SDK version 4.43
Copyright (C) 1996-2023 Markus Franz Xaver Johannes Oberhumer
Copyright (C) 1996-2023 Laszlo Molnar
Copyright (C) 2000-2023 John F. Reiser
Copyright (C) 2002-2023 Jens Medoch
Copyright (C) 1995-2023 Jean-loup Gailly and Mark Adler
Copyright (C) 1999-2006 Igor Pavlov
UPX comes with ABSOLUTELY NO WARRANTY; for details type 'upx -L'.

Any ideas why this might not be working? Thanks!

Edit:

Aha, I needed to add CGO_ENABLED=0 to the Makefile entry for dimg. I guess the default go compiler assumes glibc, which of course is not present on Alpine. Figured it out through https://stackoverflow.com/questions/34729748/installed-go-binary-not-found-in-path-on-alpine-linux-docker.

Curious, what platform do you built faktory on? Should this flag be added to the Makefile? I think it might be safest to actually do the Docker build inside a Dockerfile (perhaps using a multi-stage Dockerfile to avoid polluting the final output with build dependencies) so that the build platform matches the runtime platform.

[mperham]

I think the 127 exit code means the binary is the wrong architecture. I run aarch64 here on my M1 Pro, you might need to jigger the Makefile so it builds x86_64 by default.

[ibrahima]

It does build a multi-platform Docker image by default, so I don't think that's the issue. I think 127 actually means "not found" in some sense, and that StackOverflow link seems to suggest that it means glibc is not found in this case. I did seem to get it working when I added CGO_ENABLED=0. Not sure if that should be the default, but in any case, I'm able to test my changes now, which is awesome.

[mperham]

this is now available in 1.9