Why aren't stories being posted?

[RCscrudato]

I have one story that's been in the queue for nearly two weeks. What's the issue, and why haven't I seen any explanation?

 

[TheWritingGroup]

If you look around here and in the Authors Hangout, you'll find dozens of threads on this very topic. Answer: we don't know, but there appears to be a bug or failure of procedure where stories get stuck, like yours did.

Standard advice:

• Politely use the envelope icon up above this message to ask @Laurel (the Laurel whose profile picture is the Literotica icon) to please check the story, as it has become stuck. Make it easy for her, include a link to the story. She rarely answers, but often does unstick the story.
• If it's still stuck a week later, unsubmit it, add a Note to Moderator saying it got stuck before and please moderate it.

Say words like "Please." Laurel is not hostile, just flooded with stories to moderate and using decades-old, imperfect tools. (One person, probably part-time, is handling the technical side of this entire site.)

 

[123z]

I have a story pending since 16th April. This is the third time I have removed and re-submitted it since February and each time it just sits there waiting for approval. I have submitted stories since and they were published after only a few days in pending. I send messages to the moderators but never get a reply.

 

[TheWritingGroup]

I have a story pending since 16th April. This is the third time I have removed and re-submitted it since February and each time it just sits there waiting for approval. I have submitted stories since and they were published after only a few days in pending. I send messages to the moderators but never get a reply.

What do you mean by "send messages to the moderators"? I ask because there are no moderators. There's one person who approves stories, as far as we know, Laurel. Did you use the Conversations icon up above this thread and send to @Laurel?

Did you use this form?
https://www.literotica.com/resources/contact-literotica

Did you put notes in the "Note to Admin" section of the submission form explaining that you are resubmitting a story because it was sitting in the queue, neither accepted nor rejected?

 

[SmilingLez]

I have a story pending since 16th April. This is the third time I have removed and re-submitted it since February and each time it just sits there waiting for approval. I have submitted stories since and they were published after only a few days in pending. I send messages to the moderators but never get a reply.

That has happened to me on numerous occasions. I just recently resubmitted (as new) 2 stories that have been in pending purgatory since March and April. I changed the titles. Because of the antiquated 27 plus year-old CMS/database, I decided to see if a new title makes a difference. Perhaps there is still remnants of the old title in the database. The message thing has been ignored by the power that be. Will keep people updated

 

[Hidden_Submissive]

Yeah, I have one story stuck like this since April 6th. Never resubmitted, just pending forever. Contacted the admins but nothing as of yet.

 

[SmilingLez]

My theory based on personal experience (2 stories in pending purgatory)/-

Some stories end up in pending purgatory because the system never creates a proper internal row for them. The front end accepts the story, runs the basic checks (e.g. length) and shows you a submission date, so it looks like everything worked.

But underneath that, Literotica's 27+ year old database fails to attach the story to the moderation queue. The row is either incomplete or corrupted the moment it’s created. When that happens, the publishing script can’t see the story at all.

So the story just sits there. Not rejected. Not reviewed. Not moving. Just invisible to the part of the system that processes it.

 

[yano2mch]

So the story just sits there. Not rejected. Not reviewed. Not moving. Just invisible to the part of the system that processes it.

You'd think once a month it would run through the state of stories, and then cross reference stories against the queue and find ones that didn't get attached and.... attach them.

This seems more likely to happen if something went wrong in the string of commands. Newer databases when i was getting in some stuff in 2010 showed you'd set a session, put all your changes in, then the commit only happens if EVERYTHING went okay. If it didn't it would rollback and refuse it all, and then you could be notified what didn't go through and why.

A parallel lock issue? Semaphores are used in programming where you request a lock on a resource/variable, and if successful you access it. Otherwise you sleep a tiny bit and then try again. Too many things to lock can lock the whole system if one piece gets locked before another thread needs it and locks something else, and they are both waiting on the other to unlock.

 

[SmilingLez]

You'd think once a month it would run through the state of stories, and then cross reference stories against the queue and find ones that didn't get attached and.... attach them.

This seems more likely to happen if something went wrong in the string of commands. Newer databases when i was getting in some stuff in 2010 showed you'd set a session, put all your changes in, then the commit only happens if EVERYTHING went okay. If it didn't it would rollback and refuse it all, and then you could be notified what didn't go through and why.

A parallel lock issue? Semaphores are used in programming where you request a lock on a resource/variable, and if successful you access it. Otherwise you sleep a tiny bit and then try again. Too many things to lock can lock the whole system if one piece gets locked before another thread needs it and locks something else, and they are both waiting on the other to unlock.

If indeed my theory is true, there's no way to remove these corrupt rows because they are not able to be seen by humans. So they remain in literotica's antiquated flawed 27 plus year old database. The only solution is to migrate to a new database. But that takes human effort and there is no roi. If we paid to get our stories posted, then I am 100% sure this problem would have been fixed years ago.

What I also believe is that poetry and audio have a separate pipeline it is much cleaner because you don't have to screen for length or anything else so the work gets published within the 3 days. I have proven this with my poetry and audio, they always post in 3 days

This is my test to see if my theory is correct - on May 8th I submitted a brand new story for the loving wives category. If by chance it gets posted in the normal 3 to 5 days I will know that its row is not corrupted. Then I will delete my two stories in pending purgatory and submit them as new. Hopefully there will be no corrupted rows associated with my account since the loving wife story went through. I will keep people updated

 

[yano2mch]

If indeed my theory is true, there's no way to remove these corrupt rows because they are not able to be seen by humans. So they remain in literotica's antiquated flawed 27 plus year old database.

Don't see why not. Human's should be able to find it, since there's likely one of two things. First is a status, which will be pending/approved/rejected and possibly several rejected as negative numbers.

Each story/entry WILL have a unique ID, otherwise modifying a single row would be difficult.

Then look for those ID's that are pending without a moderator match of those ID's. Shouldn't be hard.

 

[SmilingLez]

Don't see why not. Human's should be able to find it, since there's likely one of two things. First is a status, which will be pending/approved/rejected and possibly several rejected as negative numbers.

Each story/entry WILL have a unique ID, otherwise modifying a single row would be difficult.

Then look for those ID's that are pending without a moderator match of those ID's. Shouldn't be hard.

Agreed if the database was modern, however it is 27 plus years of age and we don't know how it was created. We don't know how the rows were created.


Also the initial hyperlink placeholder is a pointer to the future location where your story will live if the backend assigns a valid row and the moderation script publishes it. If the row is corrupted, that placeholder URL points to nothing. It’s like having an address for a house that was never built.

When Laurel/Manu try to access that placeholder URL, their admin tools don’t magically reveal the story. They rely on the same backend row the system failed to create properly. If the row is dead, the interface shows no entry, no metadata, no moderation record, no text. They can’t “open” it because there is nothing to open.

They can only act on stories that exist in the moderation tables. Pending purgatory stories do not exist there, so they cannot be acted upon.

Again this is my theory, since neither Laurel or Manu have updated us it is just as valid as anyone else's theory





That is why I have my doubts

 

[yano2mch]

Agreed if the database was modern, however it is 27 plus years of age and we don't know how it was created. We don't know how the rows were created.


Also the initial hyperlink placeholder is a pointer to the future location where your story will live if the backend assigns a valid row and the moderation script publishes it. If the row is corrupted, that placeholder URL points to nothing. It’s like having an address for a house that was never built.

When Laurel/Manu try to access that placeholder URL, their admin tools don’t magically reveal the story. They rely on the same backend row the system failed to create properly. If the row is dead, the interface shows no entry, no metadata, no moderation record, no text. They can’t “open” it because there is nothing to open.

Need manual SELECT and UPDATE calls, very carefully written ones. But if they don't have access to that... then i don't know.

But contemplating about it won't do anything.

 

[Hidden_Submissive]

You can absolutely query for orphaned rows, regardless of how "old" the database is. Sorry, but this theory doesn't actually make a ton of sense.

 

[SmilingLez]

You can absolutely query for orphaned rows, regardless of how "old" the database is. Sorry, but this theory doesn't actually make a ton of sense.

Yes Laurel /Manu can query for orphaned rows and/or corrupt rows. But I don't see them doing that ,as stories are still in pending purgatory and this is happened for years. And you are also making the assumption that Laurel/Manu have the technical skills in order to query anything.

 

[123z]

What do you mean by "send messages to the moderators"? I ask because there are no moderators. There's one person who approves stories, as far as we know, Laurel. Did you use the Conversations icon up above this thread and send to @Laurel?

Did you use this form?
https://www.literotica.com/resources/contact-literotica

Did you put notes in the "Note to Admin" section of the submission form explaining that you are resubmitting a story because it was sitting in the queue, neither accepted nor rejected?

yes, i put a note in the to admin box, and again I just submitted another story 2 days ago and it will be published this Thursday. Yet STILL my pending story from 16th April is sitting there awaiting approval.

 

[TheWritingGroup]

yes, i put a note in the to admin box, and again I just submitted another story 2 days ago and it will be published this Thursday. Yet STILL my pending story from 16th April is sitting there awaiting approval.

There are dozens of other threads about this. Only Laurel can rescue your story. Some people swear by deleting the story, changing some minor thing, and resubmitting it.

 

[EmilyMiller]

I have one story that's been in the queue for nearly two weeks. What's the issue, and why haven't I seen any explanation?

https://forum.literotica.com/threads/stories-pending-over-3-weeks.1650910/#post-102464023

 

[123z]

There are dozens of other threads about this. Only Laurel can rescue your story. Some people swear by deleting the story, changing some minor thing, and resubmitting it.

I've done that with this stuck submission. First time I submitted it was February 16th, waited 5 weeks then withdrew it and re-submitted it. Waited weeks and so this is the third time. Now been pending for 4 weeks.

 

[IWroteThis]

If indeed my theory is true, there's no way to remove these corrupt rows because they are not able to be seen by humans.

I strongly disagree with you here. In the professional world, I'm a DBA, and I deal with this very issue with one system way to often (due to programmers changing web forms without understanding what they're changing).

It's not that humans can't see those records, it's that humans aren't looking at that level. They are looking at the records that the application returns when it queries the database tables. The records are there, which is why your view that queries based on submitter displays them.

Manu clearly has some DBA skills, but he seems to be primarily a programmer, so any databases issues may actually be PEBKAC instead, based on my own experience, as mentioned above.

So they remain in literotica's antiquated flawed 27 plus year old database. The only solution is to migrate to a new database. But that takes human effort and there is no roi. If we paid to get our stories posted, then I am 100% sure this problem would have been fixed years ago.

Again, I have to disagree with you. Whether they migrate to a new database or stick with the old one, fixing the issue requires rewriting code.

To expand on that a bit, I hope you don't think they're still running the same database on the same Linux kernel 2.0.x server running MySQL 3.21 that they stood up in 1998. Over the years, the database will have been migrated to new hardware, and both the OS and MySQL will have been updated to newer versions. The MySQL upgrades would have included various database integrity checks as it has to be internally upgraded to the new version as well. So, the current Literotica database is not really the same one it was 27 years ago.

While the code has also been upgraded along the way to match changes in database form and function, those are manual changes made by Manu. So, again, it comes down to the issue being the code, not the database.

What I also believe is that poetry and audio have a separate pipeline it is much cleaner because you don't have to screen for length or anything else so the work gets published within the 3 days. I have proven this with my poetry and audio, they always post in 3 days

If you're right, and those two work better because they are processed by different code, you're actually agreeing with me that the issue is in the code, not the database.

This is my test to see if my theory is correct - on May 8th I submitted a brand new story for the loving wives category. If by chance it gets posted in the normal 3 to 5 days I will know that its row is not corrupted. Then I will delete my two stories in pending purgatory and submit them as new. Hopefully there will be no corrupted rows associated with my account since the loving wife story went through. I will keep people updated

I don't think that will actually test your theory like you think. Recently, I had a story published after a fifteen day stint in Pending. During those fifteen days, I had two newer submissions get approved and published.

My best guess is that the one that was stuck for fifteen days was flagged for closer review, while the two that got published rapidly were cleared by the automated checks. So, my point is, every story is processed independently. You can't draw conclusions about one submission based on another specific one. You can only make educated guesses based on the bigger picture.

 

[SmilingLez]

I strongly disagree with you here. In the professional world, I'm a DBA, and I deal with this very issue with one system way to often (due to programmers changing web forms without understanding what they're changing).

It's not that humans can't see those records, it's that humans aren't looking at that level. They are looking at the records that the application returns when it queries the database tables. The records are there, which is why your view that queries based on submitter displays them.

Manu clearly has some DBA skills, but he seems to be primarily a programmer, so any databases issues may actually be PEBKAC instead, based on my own experience, as mentioned above.


Again, I have to disagree with you. Whether they migrate to a new database or stick with the old one, fixing the issue requires rewriting code.

To expand on that a bit, I hope you don't think they're still running the same database on the same Linux kernel 2.0.x server running MySQL 3.21 that they stood up in 1998. Over the years, the database will have been migrated to new hardware, and both the OS and MySQL will have been updated to newer versions. The MySQL upgrades would have included various database integrity checks as it has to be internally upgraded to the new version as well. So, the current Literotica database is not really the same one it was 27 years ago.

While the code has also been upgraded along the way to match changes in database form and function, those are manual changes made by Manu. So, again, it comes down to the issue being the code, not the database.


If you're right, and those two work better because they are processed by different code, you're actually agreeing with me that the issue is in the code, not the database.


I don't think that will actually test your theory like you think. Recently, I had a story published after a fifteen day stint in Pending. During those fifteen days, I had two newer submissions get approved and published.

My best guess is that the one that was stuck for fifteen days was flagged for closer review, while the two that got published rapidly were cleared by the automated checks. So, my point is, every story is processed independently. You can't draw conclusions about one submission based on another specific one. You can only make educated guesses based on the bigger picture.

Unfortunately we will never have an actual answer because Laurel/Manu will probably not update us.

The pending purgatory issue hit a high in late summer early fall which is why there was a pinned note from Laurel. So it is not a new problem.

If you read the about lit page you will see that there is no mention to any migration to a modern database. It looks like a bubblegum and super glue fix on the original database.

I filed a bug report as well as sent a PM to have my account checked to make sure there are no corrupt rows. Whether or not that will happen is a coin flip.


As I said I have three stories in pending purgatory. Two of them were originally submitted early April. After 3 weeks, I deleted them, added some extra words (changing I'm to I am) and resubmitted with a new title hoping to get a clean row. I then added a third story about a week ago hoping it would land on a clean row but it too is in pending purgatory.

I plan to enter the Geek Pride challenge and I'm hoping, with the note to admin, it bypasses the corrupt rows in my account. And it will post.

We could go with the paranoid route! since some people believe there is a white list where stories from certain people post immediately. If that is indeed correct, there could be a gray list as well as a blacklist (nothing by that author will be published). And I might be on the gray list for being the squeaky wheel.


Edit - just looked at my profile page (Latest Activity ) and got three notifications that the same author's work was published. More proof that the data base is buggy

 

[TheWritingGroup]

Edit - just looked at my profile page (Latest Activity ) and got three notifications that the same author's work was published. More proof that the data base is buggy

But it isn't. It's proof that something is buggy, but it could certainly be code.

 

[IWroteThis]

Unfortunately we will never have an actual answer because Laurel/Manu will probably not update us.

On that, I agree with you.

The pending purgatory issue hit a high in late summer early fall which is why there was a pinned note from Laurel. So it is not a new problem.

I never said it was a new problem. I said it was a code problem.

If you read the about lit page you will see that there is no mention to any migration to a modern database. It looks like a bubblegum and super glue fix on the original database.

And why would there be? Upgrading server hardware and software is routine maintenance, not something that you line item for your users. It's not like they switched from DB2 to Postgres, and they wouldn't have told us that either. They simply upgraded to newer versions of MySQL. The then-current version of MySQL has been a then-modern database consistently since before 1998.

I filed a bug report as well as sent a PM to have my account checked to make sure there are no corrupt rows. Whether or not that will happen is a coin flip.

Yeah, I question why they include the option to provide contact information when they never respond.

As I said I have three stories in pending purgatory. Two of them were originally submitted early April. After 3 weeks, I deleted them, added some extra words (changing I'm to I am) and resubmitted with a new title hoping to get a clean row. I then added a third story about a week ago hoping it would land on a clean row but it too is in pending purgatory.

I plan to enter the Geek Pride challenge and I'm hoping, with the note to admin, it bypasses the corrupt rows in my account. And it will post.

We could go with the paranoid route! since some people believe there is a white list where stories from certain people post immediately. If that is indeed correct, there could be a gray list as well as a blacklist (nothing by that author will be published). And I might be on the gray list for being the squeaky wheel.


Edit - just looked at my profile page (Latest Activity ) and got three notifications that the same author's work was published. More proof that the data base is buggy

Actually, not really. It could simply mean that author had three stories flagged for Laurel's review and she happened to review all three on the same day. It could mean that they submitted three stories on the same day, they all cleared the automated checks, and they all got approved on the same day. It's even possible that they were submitted with a note asking for them to be published together and/or on the same specific date.

And, more importantly, it does nothing to differentiate between a database issue and a code issue. Data in a record not matching query criteria is NOT a database issue, it's a data issue, which is typically a code issue, although it can be a user issue if somebody is editing records directly.

 

[SmilingLez]

On that, I agree with you.


I never said it was a new problem. I said it was a code problem.


And why would there be? Upgrading server hardware and software is routine maintenance, not something that you line item for your users. It's not like they switched from DB2 to Postgres, and they wouldn't have told us that either. They simply upgraded to newer versions of MySQL. The then-current version of MySQL has been a then-modern database consistently since before 1998.


Yeah, I question why they include the option to provide contact information when they never respond.


Actually, not really. It could simply mean that author had three stories flagged for Laurel's review and she happened to review all three on the same day. It could mean that they submitted three stories on the same day, they all cleared the automated checks, and they all got approved on the same day. It's even possible that they were submitted with a note asking for them to be published together and/or on the same specific date.

And, more importantly, it does nothing to differentiate between a database issue and a code issue. Data in a record not matching query criteria is NOT a database issue, it's a data issue, which is typically a code issue, although it can be a user issue if somebody is editing records directly.

I don't believe a human reads any story submitted. I believe it's all automated tools. YMMV. There is no proof either way

In addition, you and I have no idea what database they actually use.

There is also no ROI for Literotica to fix anything (requires labor, and time is money) unless it has to do with their advertisers links, that's where they make their money.

Actually I originally submitted the two stories in April on different dates before deleting and submitting on the same date in May and my third story was submitted on a separate day in May over a week afterwards

 

[SmilingLez]

But it isn't. It's proof that something is buggy, but it could certainly be code.

A buggy database and buggy code aren’t two separate problems on a legacy platform like Literotica - they’re the same failure expressed at different layers.

When the code that writes to the database is outdated or fragile, it creates malformed or stuck rows.

When the database contains malformed or stuck rows, the code that reads from it starts behaving unpredictably. One exposes the other. One reinforces the other. So saying “the code is buggy” but “the database is fine” doesn’t make sense; the symptoms we’re seeing - duplicate notifications, frozen submissions, phantom entries - only happen when both layers are interacting badly.

 

[IWroteThis]

I don't believe a human reads any story submitted. I believe it's all automated tools. YMMV. There is no proof either way

While I never claimed that Laurel fully reads any story, there is evidence that some level of human review does happen. One of those things is Notes to Admins. Sure, events that use a specific phrase to join can be handled with automation, but non-standardized requests that are honored clearly involved a human review. This is especially true of ones where those notes explains why a certain part of the story is going to trigger a flag erroneously.

In addition, you and I have no idea what database they actually use.

Well, it's from 2022, but the Literotica account stated they use MySQL.

A buggy database and buggy code aren’t two separate problems on a legacy platform like Literotica - they’re the same failure expressed at different layers.

Except they are separate problems, and it's important to know which it is so you can actually fix what's broken. Sure, to the average user, broken is broken. However, to the mechanic, a blown engine and a broken driveshaft are very different things.

Also, once again, they're not running outdated MySQL on outdated Linux on thirty-year-old hardware.

When the code that writes to the database is outdated or fragile, it creates malformed or stuck rows.

Yes, bad code can put bad data in the database. However, that's true of brand new code as well as old code. Also, what you call stuck rows are simply rows unmatched by the query used. The problem might just as easily be an issue with the query criteria as the data itself. Unexpected combinations of data can cause this just as well as as unexpected data. I speak from experience when I say it's easy to AND when you should OR, or OR when you should AND.

When the database contains malformed or stuck rows, the code that reads from it starts behaving unpredictably.

No. It behaves unexpectedly, but quite predictably.

One exposes the other. One reinforces the other. So saying “the code is buggy” but “the database is fine” doesn’t make sense; the symptoms we’re seeing - duplicate notifications, frozen submissions, phantom entries - only happen when both layers are interacting badly.

Maybe it doesn't make sense to you, but as somebody who actually supports web sites and the databases behind them, it makes a lot of sense to me. Actual data corruption and unexpected data are not the same thing. All those things you listed require only require faulty code to happen.

Unless that record is actually corrupted, the fact that a query doesn't return a record you want it to is a code problem. It might be the code that stored the data or the code that's querying for it (or both), but it's still a code issue. The code expecting different data is not a database issue. The database is storing what it was told to store just fine.