A couple of issues here:

1. This is repeated code that can be extracted into separate function.
2. Is it intentional not to surround this call to clearSensitiveData with try catch statement? All database queries in this class are checked against thrown exceptions. If we want an exception to be thrown here then will any exception work? Perhaps we should add some filtering to narrow the scope of exceptions ? This component is one of the most volatile in the codebase - we must be very conscious about every decision we make.
3. Is there a way to merge this functionality with handleSensitiveData? Are we sure we need to to call clearSensitiveData possibly twice? Not saying that calling at most twice is not correct, but if we can also do correct calling at most once, then we should proceed this way.

This is also repeated code that could be refactored into function.

This is repeated code that can be extracted into separate function.

Right, done

> Is it intentional not to surround this call to clearSensitiveData with try catch statement?

No, it's my mistake, thanks for pointing

Is there a way to merge this functionality with handleSensitiveData?

I am afraid it'll be hard, handleSensitiveData uses database in its logic, and in this scenario - database is malformed so it'll be hard to achieve something workable and readable simultaneously.

Are we sure we need to to call clearSensitiveData possibly twice?

Are you sure about this? after the malformed database is detected we return from this function, or do you have in mind some sort of race condition?

It is useful - let's keep it.

We're no longer using several of these directly in the dep list, so they can be removed. I'm actually not sure why the React hook ESLint rules didn't catch this

It's not clear why this one was added to the dep list... it doesn't appear to be used in the effect