relation-get -r ID remove-unit/0 still returns content

[John A Meinel]

juju deploy ./dummy-sink
juju deploy ./dummy-source
juju relate dummy-sink dummy-source
juju run --unit dummy-sink/0 -- 'relation-get -r :0 - dummy-source/0'
juju remove-unit dummy-source/0
# wait for relation-departed, etc to run
juju run --unit dummy-sink/0 -- 'relation-get -r :0 - dummy-source/0'

is returning the last set data for dummy-source/0

Note that
$ juju run --unit dummy-sink/0 -- relation-list -r :0

is returning an empty list. So it knows that dummy-sink/0 is no longer present, but relation-get still returns content.
That happens even after restarting the jujud agent, so it isn't just caching it.

You can even see that the data is still in the database:
juju:PRIMARY> db.settings.find({"_id": "20bc9e7e-4691-46ac-87f4-e4c007883c05:r#0#requirer#dummy-source/0"}).pretty()
{
        "_id" : "20bc9e7e-4691-46ac-87f4-e4c007883c05:r#0#requirer#dummy-source/0",
        "model-uuid" : "20bc9e7e-4691-46ac-87f4-e4c007883c05",
        "settings" : {
                "private-address" : "10.5.24.51",
                "ingress-address" : "10.5.24.51",
                "egress-subnets" : "10.5.24.51/32",
                "token" : "a"
        },
        "version" : NumberLong(1),
        "txn-revno" : NumberLong(3),
        "txn-queue" : [ ]
}

We probably want this data to exist during relation-departed, (how do you figure out what data was associated with the unit that is going away).
But it doesn't seem like that data should stay in the database once the unit is completely removed.