Adding tag (subject?) to book that does not exist yet causes request to fail and does not create the /subjects/<tag> entity

Yesterday I downloaded the code and walked through the installation instructions.
When I attempt to add my first book, all goes well until I edit it and try to add some tags.

According to the corresponding error.html page in errors directory:
<class 'infogami.infobase.client.ClientException'> at /books/OL3M/edit
Python /home/lillyoi/projects/latest/openlibrary/infogami/infobase/client.py in handle_error, line 74
Web POST http://sandbox.clinicalcollections.org:9999/books/OL3M/edit
Traceback (innermost first)

/home/lillyoi/projects/latest/openlibrary/infogami/infobase/client.py in handle_error
        raise ClientException(status, message, json) ...
▼ Local vars
Variable Value
data
{'at': {'key': '/works/OL3W', 'property': 'subjects'}, 'error': 'notfound', 'key': 'TAGNAME'}
error
'{"at": {"property": "subjects", "key": "/works/OL3W"}, "key": "TAGNAME", "error": "notfound"}'
json
'{"at": {"property": "subjects", "key": "/works/OL3W"}, "key": "TAGNAME", "error": "notfound"}'
message
''
self
<infogami.infobase.client.RemoteConnection instance at 0x3f12488>
status
'404 Not Found'

When I trace the path of execution, I find that the real problem is in the stack when /save_many is called. Down in infogami/infobase/writequery.py in the SaveProcessor class, the process_many function calls the _process function for each of the docs.

It appears as though an attempt to retrieve an entity with key = "TAGNAME" fails, the 404 bubbles up and the whole save request fails.

For example, on your production site, a search for books re; solr (http://openlibrary.org/search?q=solr) includes David Smiley's book "Solr 1.4".

I see that Edward added the book and added some tags (SOLR, Lucene, enterprise search, for example) and clearly the solr index is working, since searches over those terms return this book.

The production version obviously allows me to add tags (I just added "fuzzy queries, ranked scoring") and I would expect to see search results later when the index is updated, but it appears that the trunk version of code is currently broken.