#Heroku worker setup issues

1 messages · Page 1 of 1 (latest)

final yew
#

I can run a worker locally, but on Heroku I get the following:
2025-06-20T12:20:29.858319+00:00 app[worker.1]: [ ERROR ] command failed [error: handshakeFailed(NIOSSL.BoringSSLError.sslError([Error: 268435581 error:1000007d:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED at /tmp/build_55077d23/.build/checkouts/swift-nio-ssl/Sources/CNIOBoringSSL/ssl/handshake.cc:393])), rdstk_conn_id: 8934EEAA-96D3-4250-B8DE-DA0525F3F144, rdstk_conpool_id: 2F0193F2-8D35-4CCB-907D-44E88F9F0F0F]
2025-06-20T12:20:29.858786+00:00 app[worker.1]: [ ERROR ] failed to create connection for pool [error: ioOnClosedChannel, rdstk_conpool_id: 2F0193F2-8D35-4CCB-907D-44E88F9F0F0F]
2025-06-20T12:20:29.913324+00:00 heroku[worker.1]: Process exited with status 0

I can't find anything in the docs or online about this, even tried the following hacky attempt in configure.swift to get around it:
var tls = TLSConfiguration.makeClientConfiguration()
tls.certificateVerification = .none
redisConfig.tlsConfiguration = tls

Nothing going my way today.

My proc file calls it with: worker: Run queues --env production

What am I missing here? Happy to give more context if needed!

brittle tiger
#

That should be enough for Heroku's Redis

#

I'm assuming you've redeployed etc?

final yew
#

Yeah redeployed and restarted multiple times. Tried to fire up the worker from CLI. This is my redis config code ... any obvious errors?

var redisConfig = try RedisConfiguration(url: redisURL)

if environment != "development" {
    var tls = TLSConfiguration.makeClientConfiguration()
    tls.certificateVerification = .none
    redisConfig.tlsConfiguration = tls
}

app.redis.configuration = redisConfig
app.queues.use(.redis(redisConfig))

app.queues.add(InputGenerationJob())

if environment == "development" {
    try app.queues.startInProcessJobs(on: .default)
}
vale wolf
#

can you share your Procfile?

final yew
#

web: App serve --env production --hostname 0.0.0.0 --port $PORT
worker: Run queues --env production

vale wolf
#

That App/Run dichotomy is very suspicious

#

shouldn't it be App on both lines?

final yew
#

I previously had it as worker: App queues and iirc it was the same result

#

let me try redeploy with that to verify

vale wolf
#

I would assume that if your project really has two separate entry points (executable targets), you would consciously know about it

final yew
#

Yeah, you're right, certainly not the case. I've been tied up in knots trying everything

brittle tiger
#

The if environment == "development" is weird as well, where does that come from?

vale wolf
#

I would assume it stems from the practice inside Vapor and its examples to make things different depending on the environment as opposed to having granular configuration 😏

#

you wouldn't need a tls config if you rawdog redis locally

final yew
#

Well yeah, it's just something I have set from config vars to have that granular control. And yep the tls config stuff there has just been my hacky attempts to fix it, like I said, didn't need any of that locally. Heroku is still a bit of a mystery to me, as you can probably tell

vale wolf
#

@final yew perhaps you could change that condition up? If the redis URL starts with rediss:, use TLS

#

this would evade a weird situation if the queues command doesn't handle the env parameter, or something...

#

(never used queues myself)

brittle tiger
final yew
#

Yeah, enum would be better for sure.

Okay, so running as worker: App queues, it does work. Kind of. It loads the worker, and runs the process. Front end proceeds, as if it has got a response, even though it hasn't. Five mins later, I get:

2025-06-20T15:26:39.089680+00:00 app[worker.1]: Current ENV: production
2025-06-20T15:26:39.089696+00:00 app[worker.1]: ✅ Inputs generated OK: InputResponse(p...

Seen anything like that before?

brittle tiger
#

Those would be your logs

final yew
#

Of course, I more meant that behaviour

#

sorry for the mega thread. I'm a bit alone with this

vale wolf
#

you're not alone here, but you know, without seeing more of the code there's only so much we can do

final yew
#

yeah, ofc. Well, even just that clarity around the procfile is helpful direction. Going to step away and come back to it with fresh eyes tomorrow

#

Thanks both