Ordered persistence within a Propel transaction

Question

I'm trying to make use of a lifecycle callback in Propel, postInsert. The issue that I'm running into is that there is a chicken/egg scenario due to the persistence ordering of INSERTs and database FK constraints.

In the callback, I need the current object/record to be persisted, which you would think would be the case by the time the postInsert method is executed. However, that does not seems to be happening (I haven't dug into the Propel lib to confirm yet). I'm not sure if this is a bug/otherwise, or the fact that it's in a Propel transaction and persistence is handled later in the lifecycle (surely hoping that's not the case).

Since this is a postInsert callback and it's not actually being persisted prior, I'm unable to force a save() at this point, as that results in a endless loop.

I'm running out of ideas, outside of refactoring all the code around this to handle it independently by forcing persistence.

Firstly, can someone confirm if persistence, within a transaction, should occur before a postInsert, thereby making an auto-incremented primary key value available?

If that's not the intended functionality, is there a way to instruct Propel on the order of INSERTs for which to respect within a given transaction?

Example code if the above isn't clear:

$con = Propel::getConnection()
$con->beginTransaction();
$foo = new \Foo();
$foo->save();
$con->commit();

Foo Model

class Foo extends BaseFoo
{
    public function postInsert()
    {
        if (!$this->getId())
            throw new Exception("id is not available.");
    }
}