Replication stops with GTID_NEXT error after creation/drop of memory table in mysql5.6
I encountered a similar problem that generated the same error. On a master instance I dropped a database.
On a slave there was a file left over &lt;tablename&gt;.exp (I forget what purpose this serves).
The slave replication died with

last_Error: Error 'DROP DATABASE failed; some tables may have been
dropped but the database directory remains. The GTID has not been
added to GTID_EXECUTED and the statement was not written to the binary
log. Fix this as follows: (1) remove all files from the database
directory ./db_to_drop/; (2) SET
GTID_NEXT='c62b6474-84e6-11e8-bf49-00164ef9ea6c:73066506'; (3) DROP
DATABASE db_to_drop.' on query. Default database: 'db_to_drop'.
Query: 'drop database db_to_drop'

I removed the file, ran the SET and restarted replication:

SET GTID_NEXT='c62b6474-84e6-11e8-bf49-00164ef9ea6c:73066506';
start slave; ERROR 1837 (HY000): When @@SESSION.GTID_NEXT is set to a
GTID, you must explicitly set it to a different value after a COMMIT
or ROLLBACK. Please check GTID_NEXT variable manual page for detailed
explanation. Current @@SESSION.GTID_NEXT is
'c62b6474-84e6-11e8-bf49-00164ef9ea6c:73066506'.

And this, from following the suggestion. Since it's only a development cluster, I wasn't worried about losing it entirely, so I punted and tried setting it to the next GTID.
SET GTID_NEXT='c62b6474-84e6-11e8-bf49-00164ef9ea6c:73066507';
(i.e. + 1). Restarted replication and things got back to normal.