client.status(:post, msg) not working

[Mark Granoff]

There must be something I am doing wrong, but for the life of me, I
cannot see it.

I have a cron job that runs a Ruby script. The script selects a status
message to post and trys to do so. The crux of what I am doing is:

client = Twitter::Client.new(:login =>
'username',
:password =>
'password')

s = client.status(:post, msg)

I have this in a begin/rescue/end block, etc. No error is reported,
and the status is not posted. Makes no sense to me; it seems like it
should work.

Any suggestions appreciated. Happy to provide more detail if
necessary.

Thanks,
-Mark

[SP]

How long is the message?

[SP]

Also could you tell me which version you are using?

Thanks,
Susan

[Mark Granoff]

Messages are all under 140 characters. The script selects from an
array of messages randomly, but only after filtering out messages that
might be longer than 140 characters.

I am using twitter4r v0.3.2

By the way, I am big fan of Ruby and your t4r implementation is very
nice! Well done.

Thanks for the help.

-Mark

[Mark Granoff]

I should say that I see *intermittent* success. That is to say,
occasionally a status post gets through.

For what it's worth, I see intermittent success using either of the
following patterns:

client = Twitter::Client.new(:login => username, :password =>
password)
s = Twitter::Status.create(:client => client, :text => "#{msg}")

or

client = Twitter::Client.new(:login => username, :password =>
password)

s = client.status(:post, msg)

Using either pattern, when the status is NOT posted, there is no error
raised or any indication of failure other than the fact that no status
shows up when viewing Twitter via something like Tweetdeck.

-Mark

On Feb 12, 10:58 am, SP <mbbx6...@gmail.com> wrote:

[Mark Granoff]

Well, I may have just discovered the "problem." No problem with
twitter4r, it would appear, but rather this is "expected" behavior
from the Twitter API (as of late Fall '09, I think) where a duplicate
Tweet (and not a duplicate of the last tweet) is not posted, and NO
error is reported.

I read about this in the Twitter bug list here:

http://code.google.com/p/twitter-api/issues/detail?id=1126&q=post%20fails&colspec=ID%20Stars%20Type%20Status%20Priority%20Owner%20Summary%20Opened%20Modified%20Component

The "workarounds" include checking timelines and such, so I'll have to
go back to the drawing board and see what I can figure out to get
around this. (I suppose if I included some unique value in my canned
tweets that would make them not look like dups.... but that is ugly.)

-Mark

[Mark Granoff]

Did you ever discover anything about this? I did notice some test
posts you made, so of course, that made things appear to work.

I switched to this model:

client = Twitter::Client.new(:login => username,
:password => password)

s = Twitter::Status.create(:client => client,

:text => msg)

and it works more often but not 100% of the time.

I realize that Twitter is not what anyone would called a guaranteed
service, and that is fine. What would be nice, though, is if twitter4r
would provide some feedback that the post worked or not.

Might it be the case that the twitter4r API calls are "working", as
far as the API is concerned, but something else, within the Twitter
network, is going awry? (I suppose it could be...) Surprising, though,
only because *sometimes* the API does get an error response back from
Twitter (when it's too busy or something).

I really want this to work reliably, and I am disappointed that it
doesn't. This is NOT a reflection on twitter4r, but sadly, on Twitter,
I think.

I'd be very interested in other ways to achieve my goal, which is to
post a tweet in a consistent, automated fashion. Right now, it's
automated, but not consistent. :-)

Thanks,
-Mark

[SP]

Mark,

I am not ignoring you I am just returning from vacation (at the
airport now) and will respond in the next day or two after I get my
bearings again.

Susan

[Mark Granoff]

Thanks, Susan. No worries!

As you can see from my second message yesterday, I found the real
issue, which is Twitter, not twitter4r. :-)

My proposed solution, which was to append a unique id to each tweet,
worked!

I'd prefer if my tweets didn't have to include such a thing, but it
works now, and quite consistently.

You're off the hook. ;-)

-Mark

P.S. What i did was take my message and append Time.now.tv_usec
formatted as a hex value.