This is the mirrorlist whose URLs are not treated properly by DNF in my case:
https://raw.githubusercontent.com/UnitedRPMs/unitedrpms/master/mirrorlist_x86_64.txt

Content:
https://sourceforge.net/projects/unitedrpms/files/$releasever/$basearch/
https://osdn.net/projects/unitedrpms/storage/$releasever/$basearch/

My guess is that many repositories which use that style of mirrorlist are affected.

I can't reproduce this. If I take fedora repos and use baseurl (including both $releasever and $basearch) instead of mirrorlist, dnf still resolves that ok and pulls the metadata.
dnf-3.6.1-1.fc29.noarch

Michael, please upload the repo file that doesn't work for you.

Somebody implemented a workaround (!) on UnitedRPMs side already (see https://github.com/UnitedRPMs/unitedrpms/commit/30c505cadaf0145986f7eae938573a32ba7a6316).

However, that doesn't fix the root cause of the issue...

Here's the (original) repo file I was writing about:

/etc/yum.repos.d/unitedrpms.repo:
---------------------------------------------
[unitedrpms]
name=unitedrpms $releasever - $basearch
mirrorlist=https://raw.githubusercontent.com/UnitedRPMs/unitedrpms/master/mirrorlist_x86_64.txt
baseurl=https://sourceforge.net/projects/unitedrpms/files/$releasever/$basearch/
enabled=1
priority=1
metadata_expire=1d
skip_if_unavailable=1
gpgkey=file:///etc/pki/rpm-gpg/URPMS-GPG-PUBLICKEY-Fedora-24
gpgcheck=1
repo_gpgcheck=1
enabled_metadata=1
---------------------------------------------

The original state of the repository file, I mentioned, can also be obtained by using the previous version: https://github.com/UnitedRPMs/unitedrpms/releases/download/8/unitedrpms-29-8.fc29.noarch.rpm

OK, also I got confused by metalink vs mirrorlist. Nevertheless, in a repo with this:

mirrorlist=https://raw.githubusercontent.com/UnitedRPMs/unitedrpms/master/mirrorlist_x86_64.txt

I can reproduce the problem. The hyperlink returns this content:

https://sourceforge.net/projects/unitedrpms/files/$releasever/$basearch/
https://osdn.net/projects/unitedrpms/storage/$releasever/$basearch/

at that's later used literally. So it seems that the variables are replaced in baseurl/metalink/mirrorlist values, but not in mirrorlist _content_. I don't know whether that's expected or not (as you say, it worked before). Now we need feedback from DNF devs.

Exactly. :-)
The content (URLs of the mirrors) inside the mirrorlist file isn't treated right in my opinion.

I'm very certain that it worked fine the last time I used fedora 28.

I'm not sure this was supposed to work. My understanding is that the mirrorlist text file itself was supposed to be variable substituted, and it would pass in a literal newline separated list of _valid_ URLs.

If this worked before, I'm not sure it was supposed to...

(In reply to Michael from comment #6)
> I'm very certain that it worked fine the last time I used fedora 28.

Confirmed, it works fine with dnf-2.7.5-12.fc28. That doesn't mean it was a documented supported behavior, of course.

(In reply to Neal Gompa from comment #7)
> I'm not sure this was supposed to work. My understanding is that the
> mirrorlist text file itself was supposed to be variable substituted, and it
> would pass in a literal newline separated list of _valid_ URLs.
> 
> If this worked before, I'm not sure it was supposed to...

Sorry, I meant mirrorlist text file URL path, not the file content.

PR https://github.com/rpm-software-management/dnf/pull/1244

Discussed during the 2018-10-15 blocker review meeting: [1]

The decision to classify this bug as a "RejectedBlocker" and an "AcceptedFreezeException" was made as this is not believed to affect any official / out-of-the-box repositories and thus does not break any release criteria. As this could benefit some folks on first boot, it is accepted as a freeze exception if the fix is simple and testable.

[1] https://meetbot.fedoraproject.org/fedora-blocker-review/2018-10-15/f29-blocker-review.2018-10-15-16.00.txt

*** Bug 1645413 has been marked as a duplicate of this bug. ***

*** Bug 1646894 has been marked as a duplicate of this bug. ***

libdnf-0.22.3-1.fc29 dnf-4.0.9-1.fc29 dnf-plugins-core-4.0.2-1.fc29 dnf-plugins-extras-4.0.0-1.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-17cbc3c616

dnf-4.0.9-1.fc29, dnf-plugins-core-4.0.2-1.fc29, dnf-plugins-extras-4.0.0-1.fc29, libdnf-0.22.3-1.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-17cbc3c616

dnf-4.0.9-1.fc29, dnf-plugins-core-4.0.2-1.fc29, dnf-plugins-extras-4.0.0-1.fc29, libdnf-0.22.3-1.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.

On Fedora 29 I'm seeing Failed to synchronize cache for repo 'unitedrpms'

I have:
mirrorlist=https://sourceforge.net/projects/unitedrpms/files/29/x86_64/
baseurl=https://osdn.net/projects/unitedrpms/storage/29/x86_64/

Based on: https://github.com/UnitedRPMs/unitedrpms/commit/30c505cadaf0145986f7eae938573a32ba7a6316