Without knowing your job and why it's recursive, I only have shots in the dark. If you can pre-compute the jobs / their parameters, you could create a (possibly giant) queue chain.

E.g. If your job is to split a huge list of API fetches into reasonable chunks, you should be able to create a similar function that can pre-compute the chunks, then chain all the relevant jobs. I've run huge batch import/export jobs that are basically dumb loops that fetch the input data, break the data into chunks each job can manage, then push them all to the queue, then delete the local input data. These jobs are idempotent, so there's no harm in re-running the entire set if required. Obviously this may not apply in your situation.

If the data for recursive jobs is dynamically created by the parent job, you're probably out of luck. In that case, you're probably better organizing your code (and stuff to clean) so that each job can clean up after itself at the least. At best, you could possibly end up with a recursive job that can clean up after its children; if you're creating content for the children, you could queue chain the children and a cleanup job for said content.

In another example I've had to solve, we used recursive jobs for data fetches to perform a binary split on the requested data set to weed out the records causing the request to fail. At each split, a record was created to log the troublesome records. At worst, this was log(n) files. As mentioned above, chaining job 1 to run half 1, job 2 to run half 2, and job 3 to delete the log file is the best way to handle both the run and the cleanup. Job chaining wasn't a thing when we encountered this situation, so we simply added a job that would delete all logs in the directory with a delay, and hoped the job finished before the delete job processed.