My story in a nutshell
----------------------

1. observe the effect [bug 1953782]
2. find that kbd-2.4.0-4.fc35 fixes the problem
3. look at the package history for kbd to check where
   we stand in this matter:

# dnf history kbd
> ID     | Command line   | Date and time    | Action(s)      | Altered
> ---------------------- ----------------------------------------------
>     52 | update         | 2021-04-26 09:57 | E, I, U        |   93  <
> [...]

Short of exact version check on the installed system, I can deduce
that this machine did not receive the fix yet per the last time
this package was allegedly touched...  But really?

$ rpm -q kbd
> kbd-2.4.0-4.fc35.x86_64

Oh, so something doesn't play quite right.


Further investigation
---------------------

- I know for sure that the kbd package was updated in this
  transaction:

> Transaction ID : 75
> Begin time     : Mon 03 May 2021 12:08:59 PM CEST
> Begin rpmdb    : 1312:...
> End time       : Mon 03 May 2021 12:14:12 PM CEST (5 minutes)
> End rpmdb      : 1315:...
> User           :  <user>
> Return-Code    : Failure: 1
> Releasever     : rawhide
> Command Line   : update
> Comment        : 
> Packages Altered:
> [...]
>     Upgrade  copy-jdk-configs-4.0-0.fc35.noarch                                  @rawhide
>     Upgraded copy-jdk-configs-3.7-8.fc34.noarch                                  @@System
> [...]
>  ** Upgrade  java-11-openjdk-headless-1:11.0.11.0.9-2.fc35.x86_64                @rawhide
>  ** Upgraded java-11-openjdk-headless-1:11.0.11.0.7-0.1.ea.fc35.x86_64           @@System
>     Upgrade  kbd-2.4.0-4.fc35.x86_64                                             @rawhide
>     Upgraded kbd-2.4.0-3.fc35.x86_64                                             @@System
>     Upgrade  kbd-legacy-2.4.0-4.fc35.noarch                                      @rawhide
>     Upgraded kbd-legacy-2.4.0-3.fc35.noarch                                      @@System
>     Upgrade  kbd-misc-2.4.0-4.fc35.noarch                                        @rawhide
>     Upgraded kbd-misc-2.4.0-3.fc35.noarch                                        @@System
> [...]
>     Upgrade  lua-5.4.3-1.fc35.x86_64                                             @rawhide
>     Upgraded lua-5.4.2-2.fc34.x86_64                                             @@System
>     Upgrade  lua-libs-5.4.3-1.fc35.x86_64                                        @rawhide
>     Upgraded lua-libs-5.4.2-2.fc34.x86_64                                        @@System
> [...]
>     Upgrade  rpm-4.16.90-0.git15395.5.fc35.x86_64                                @rawhide
>     Upgraded rpm-4.16.1.3-1.fc35.x86_64                                          @@System
>     Upgrade  rpm-build-libs-4.16.90-0.git15395.5.fc35.x86_64                     @rawhide
>     Upgraded rpm-build-libs-4.16.1.3-1.fc35.x86_64                               @@System
>     Upgrade  rpm-libs-4.16.90-0.git15395.5.fc35.x86_64                           @rawhide
>     Upgraded rpm-libs-4.16.1.3-1.fc35.x86_64                                     @@System
>     Upgrade  rpm-plugin-selinux-4.16.90-0.git15395.5.fc35.x86_64                 @rawhide
>     Upgraded rpm-plugin-selinux-4.16.1.3-1.fc35.x86_64                           @@System
>     Upgrade  rpm-plugin-systemd-inhibit-4.16.90-0.git15395.5.fc35.x86_64         @rawhide
>     Upgraded rpm-plugin-systemd-inhibit-4.16.1.3-1.fc35.x86_64                   @@System
>     Upgrade  rpm-sign-libs-4.16.90-0.git15395.5.fc35.x86_64                      @rawhide
>     Upgraded rpm-sign-libs-4.16.1.3-1.fc35.x86_64                                @@System
> [...]
> Scriptlet output:
>    1 error: lua script failed: /var/lib/rpm-state//copy_jdk_configs.lua:215: bad argument #1 to 'gsub' (string expected, got nil)
>    2 error: java-11-openjdk-headless-1:11.0.11.0.9-2.fc35.x86_64: install skipped
>    3 error: java-11-openjdk-headless-1:11.0.11.0.7-0.1.ea.fc35.x86_64: erase skipped

This transaction expressly denoted itself as "failed", IIRC[*].

The underlying cause is getting attention elsewhere, not so important
here [bug 1954998 comment 5].

But this very report aims to get the package-name-to-transaction-records
mapping into accordance with reality, which is apparently tracked rather
legitimately when querying history for a particular transaction
(here "dnf history info 75").

Yet, per-package query ("dnf history kbd" as mentioned) is lacking behind
in these non-happy cases.

(I assert it is safe to exclude that this "amnesia" could be caused with
both RPM and Lua being updated as part of the failed transaction, see
the bug stated in connection to "underlying cause".)

So, the consistency expectations around transactions -- in this context
around keeping track thereof for the purpose of "history" queries --
would preferably be bounded/conceptualized more clearly.  Perhaps with
some extra effort once dnf observes such a failure, i.e., reconcile
what was indeed installed per RPM DB and reflect that viably in
"history" tracking.  In short, "better effort" to avoid such confusions.

Thanks for considering.

---

$ rpm -q dnf rpm
> dnf-4.6.1-1.fc35.noarch
> rpm-4.16.90-0.git15395.5.fc35.x86_64

---

[*] Looking into /var/log/dnf.log, there's this regarding the failure
    of the transaction:

> 2021-05-03T12:14:48+0200 SUBDEBUG 
> Traceback (most recent call last):
>   File "/usr/lib/python3.9/site-packages/dnf/cli/main.py", line 67, in main
>     return _main(base, args, cli_class, option_parser_class)
>   File "/usr/lib/python3.9/site-packages/dnf/cli/main.py", line 106, in _main
>     return cli_run(cli, base)
>   File "/usr/lib/python3.9/site-packages/dnf/cli/main.py", line 130, in cli_run
>     ret = resolving(cli, base)
>   File "/usr/lib/python3.9/site-packages/dnf/cli/main.py", line 176, in resolving
>     base.do_transaction(display=displays)
>   File "/usr/lib/python3.9/site-packages/dnf/cli/cli.py", line 264, in do_transaction
>     raise dnf.exceptions.Error(_('Transaction failed'))
> dnf.exceptions.Error: Transaction failed
> 2021-05-03T12:14:48+0200 CRITICAL Error: Transaction failed