[Bug]: Centralized filebucket not working properly

[mdechiaro]

Is this a critical security issue?

• This is not a security issue.

Describe the Bug

I originally posted this Issue to puppetlabs, but have
since migrated to Openvox, so opening another issue here.

Here is the documentation
for setting up centralized filebuckets, however it does not appear to work properly.

After setting up filebucket resource in site.pp, the filebuckets are still stored with the puppetserver that compiled the catalog, instead of being sent to the location configured in the filebucket resource.

Expected Behavior

I expect the configured filebucket resource to get these files, instead of the puppetserver that compiled the catalog.

Steps to Reproduce

Steps to reproduce:

1. Configure remote filebucket. This should be a separate puppetserver than the one compiling the catalog for the agent. I used PuppetCA puppetserver for this example.

# site.pp

filebucket { 'puppetca':
  server => 'puppetca.hostname.com',
  path   => false,
}

File {
  backup => 'puppetca',
}

2. Verify auth.conf permissions on puppetserver are correct

auth.conf
        {
            # Allow nodes to access all file_bucket_files.  Note that access for
            # the 'delete' method is forbidden by Puppet regardless of the
            # configuration of this rule.
            match-request: {
                path: "/puppet/v3/file_bucket_file"
                type: path
                method: [get, head, post, put]
            }
            allow: "*"
            sort-order: 500
            name: "puppetlabs file bucket file"
        },

3. Make a local change to a managed file on the agent side, then run Puppet
   agent to have it revert it back.

Info: /Stage[main]/Motd/File[/etc/motd]: Filebucketed /etc/motd to puppetca with sum 0969e80061625526e4e611e8cd6e43e3ead5a2b87071e6393249c72e0f7765c5

4. Check the location of the file. It will not be sent to the location configured in filebucket resource. Instead, it will reside on the puppetserver that compiled the catalog.

Environment

Version 8.25.0
Platform Ubuntu 24.04 and RHEL8

Additional Context

I have a remote branch that includes a fix. I used Claude to help assist how the filebucket code works, and find a solution to the problem. I also asked Claude to review the git log and find out when this feature broke. Here's what it found.

● Here's what the history shows:

request.server was never included in the new HTTP client implementation from the start. There are two relevant commits:

1. 52d3dcb (PUP-10385) — "Change filebucket terminus to use http client" (Melissa Stone, Apr 2 2020)
   - This introduced the new HTTP client path using session.route_to(:puppet) with no URL argument — request.server was simply never wired in.
   - A use_http_client? guard was added to fall back to super (the old Puppet::Indirector::REST base class, which did handle request.server).
2. d7fdd56 (PUP-10440) — "Always use HTTP client for REST requests" (Josh Cooper, Jul 29 2020)
   - This removed the use_http_client? guards entirely, making the new path unconditional.
   - The commit message explicitly states: "Since the HTTP client handles resolution based on SRV records and settings, remove the use_srv_service and use_(server|port)_setting calls from
   the individual rest termini."
   - This closed off the last escape hatch (super) that preserved request.server support.

So the initial omission was in 52d3dcb (PUP-10385), and the final removal of any fallback was in d7fdd56 (PUP-10440). The assumption in PUP-10440 was that route_to(:puppet) would
handle server selection — but that doesn't account for the centralized filebucket case where request.server explicitly points to a different host.

Relevant log output

No errors in the logs, and this issue appears to silently fail.