Feature suggestion: Unwrap ActiveJob wrapped Job names in the WebUI about faktory HOT 6 CLOSED

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

from faktory.

Ah great thanks, that's really helpful!

from faktory.

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.

from faktory.

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.

from faktory.

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.

from faktory.

this is now available in 1.9

from faktory.