Availability Group database stays in Reverting for too long after a failover
One thing to check whenever database recovery is running long, whether it's a normal restore or an AG failover, is your VLF count.  Having lots of VLFs (thousands or tens of thousands), or VLFs of unusual size (one or two extremely large VLFs) will cause this process to slow to a crawl.

Run the following command on your the database in question:

USE YourDatabaseName;
GO

DBCC LOGINFO;


Note: if you're on SQL Server 2016 SP2 or newer, you can use this dynamic management function instead of the DBCC command: sys.dm_db_log_info

The number of rows that comes back is the number of VLFs you have.  If that number is very large, or if the FileSize column shows extreme outliers among your VLFs, then you can likely resolve the slow recovery problem by (at a high level):


shrinking the log file as small as possible
growing it back out to its target size
making sure autogrowth is set to a reasonable number based on your typical log growth rate and the frequency of your transaction log backups


The details of fixing VLF sizing issues have been covered extensively elsewhere, here is one example: A Busy/Accidental DBA’s Guide to Managing VLFs