Opened 13 years ago

Last modified 13 years ago

#231 closed defect (WONTFIX)

Ambiguous mongodb version dependency

Reported by: Caleb Davis Owned by: Caleb Davis
Priority: minor Milestone:
Component: Keywords:
Cc: Parent Tickets:

Description

I unwittingly triggered an extra MongoDB version dependency because
I was running MongoDB v1.2.2 on omgmg (bad Caleb, bad!). The
symptom is as follows:


-  media items show up on root.html, but the link to
   /u/this-is-my-slug gave 404 errors. However, the
   /u/objectid\_string link worked. That is, until later Elrond found
   one for which the slug link 404'ed and the objectID link 500'ed. I
   don't have the traceback.

Chris investigated, figured out the problem was probably a MongoDB
version issue, cleaned up the mess by upgrading MongoDB, and
narrowed the issue down to older MongoDBs not being able to drop
indexes...or something like that. The exact cause remains unknown,
but what is known is that there is another MongoDB version
dependency lurking in the inky shadows somewhere between v1.2.2 and
v1.8.3.

If the dependency is met by v1.3 then the docs are correct.
Otherwise the docs are incorrect.

We could narrow down the version dependency in two ways:


1. Actively by stepping through MongoDB releases on one machine
   from v1.2.2 until the ambiguously defined issue is resolved.
2. Passively by keeping an eye out for this error in IRC, and
   asking users to report their MongoDB versions here before
   updating.

I'm happy to do `#1 </issues/1>`_ using the old omgmg envball and
Chris's 404 test (below). Meanwhile please consider #2.

test -
`http://omgmg.dyndns.org:6543/u/isylja/m/spielkind-2/ <http://omgmg.dyndns.org:6543/u/isylja/m/spielkind-2/>`_
gives 404 error. First MongoDB version without the 404 error meets
the "dependency." That's the best I can think of for now.



Change History (3)

comment:1 by Caleb Davis, 13 years ago

Status: NewClosed
I was hoping to make progress using the version sweep (approach
`#1 </issues/1>`_), and then I realized it was pretty much a waste
of time. While I did see a change in behavior at v1.6.0, that
really doesn't mean much. Since we don't know how the index
originally got hosed, there's not much we can do except #2. Oh
well.

I'm going to close this bug, but we can re-open it if it happens to
anyone else.



comment:2 by Christopher Allan Webber, 13 years ago

Status: ClosedRejected
Marking it as rejected because we didn't fix anything. I kind of
hate how harsh "rejected" sounds though. :)

Agreed on the \*non-)resolution for now though. Let's see what
happens. Could be a fluke.



comment:3 by Will Kahn-Greene, 12 years ago

The original url for this bug was http://bugs.foocorp.net/issues/541 .
Relations:
#185: related

Note: See TracTickets for help on using tickets.