Running the W3C EME test drm-mp4-playback-retrieve-persistent-license.html hits the following DCHECK:

[1:1:1123/152037:FATAL:webcontentdecryptionmodulesession_impl.cc(443)] Check failed: !has_close_been_called_. 
#0 0x7efc144cf74e base::debug::StackTrace::StackTrace()
#1 0x7efc145366fc logging::LogMessage::~LogMessage()
#2 0x7efbfcdf1bfb media::WebContentDecryptionModuleSessionImpl::close()
#3 0x7efbf7edb6af blink::MediaKeySession::closeTask()
#4 0x7efbf7ed9415 blink::MediaKeySession::actionTimerFired()
#5 0x7efbf7dac3a1 blink::TaskRunnerTimer<>::fired()
#6 0x7efc018d8453 blink::TimerBase::runInternal()

The test does the following:
        function onTimeupdate(event) {
            if ( config.video.currentTime > ( config.duration || 1 ) ) {
                config.video.pause();
                _mediaKeySession.close();
            }
        }

It looks like 2 timeupdate events occur close together (e.g. timestamps 1.147568, 1.148347), so that the first close() hasn't completed before the second close() attempt.

The current EME spec states:

http://w3c.github.io/encrypted-media/#dom-mediakeysession-close
step 2: If session is closed, return a resolved promise.
step 5.3: Queue a task to run the following steps:
step 5.3.1: Run the Session Closed algorithm on the session.

"closed" from step 2 links to http://w3c.github.io/encrypted-media/#media-key-session-closed, which states "MediaKeySession object is closed if and only if the Session Closed algorithm has been run." Since it's done in a task, a second close() call could also queue a task to close the session a second time.

Calling close() multiple times close together should do something reasonable.