I am using yowsup-cli, and it prints the following when I run "yowsup-cli version" ...
yowsup-cli v2.0.13
Using yowsup v2.4
I am trying to perform the registration as specified in the yowsup documentation, as follows. However, it fails.
First, I entered this command, and I indeed got a code back via SMS ...
yowsup-cli registration --requestcode sms --phone 1XXXXXXXXXX --cc 1 --mcc 310 --mnc 260
I then entered this command using the code I got back (shown as "AAA-BBB"), but it failed ...
yowsup-cli registration --register AAA-BBB --phone 1XXXXXXXXXX --cc 1
This is the error message I received ...
status: fail
reason: missing
What I did above is exactly what is described in the yowsup documentation, here: https://github.com/tgalal/yowsup/wiki/yowsup-cli-2.0#yowsup-cli-registration%29 (see the commands listed under "Example:").
Note that I get the same failure when I add the MNC and MCC info to the "--register" command.
Does anyone know why this registration procedure is failing, and what might be "missing" in what I'm doing?
Note that the MCC and MNC I specified are what I found when looking up my cell provider (T-Mobile, USA).
Also, note that I am able to run WhatsApp with no problems from my mobile device, as well as via their web interface.
Thanks for any help and suggestions.
you do not have to put "-" in your otp/code. it will be a plain sms code
yowsup-cli registration --register AAABBB --phone 1XXXXXXXXXX --cc 1
i hope it works
Related
We are trying to replicate data from AlloyDB to Bigquery using Datastream.
We Get "An unknown error occurred. Please try again. If the error persists, contact Google support."
In the Datastream console --> objects list, we see all source tables with Object Status "Failed" and Backfill status "Completed".
In Bigquery we see only a subset of the tables (not all the "Completed" objects were synced).
In the Logs Explorer I can see this error on BQ:
I also see this error: error: {
code: 11
message: "Unsupported primary key column either does not exist or is a pseudocolumn at [1:401]"
}
The column referred in the error is of type enum.
The desired situation is having all the AlloyDB tables replicated into Bigquery.
The error message is not very informative...
What does it mean?
What would be the best way to go about troubleshooting this?
We're actively working on making these error messages be more informative, and improvements are continuously being rolled out as we identify more edge cases. Assuming you followed all the steps in the documentation, then you may need to open a ticket with support for further investigation. If a support ticket isn't an option, you can still report the issue using the public issue tracker
I just had this same issue but connecting to a PostgreSQL in AWS RDS:
Beginning with Postgres 10, passwords are encrypted using SCRAM-SHA-256 in PostgreSQL. Google DataStream still expects MD5 password encryption, or it will generate an "unknown error" in the logs and fail the backfills.
You'll need to update your postgresql.conf (or RDS Cluster Parameter Group if you're using AWS like me):
password_encryption = 'MD5'
Restart the database and make sure the parameter has changed with:
SHOW password_encryption;
Reset the password of your users:
ALTER USER "{username}" with password '{password}';
More info from the PostgreSQL docs: https://www.postgresql.org/docs/current/auth-password.html
got error when calling package
error is
Error starting at line : 1 in command -
PKG_Generate_GRNo.GenerateGR(TO_NUMBER(:P164_APP_ID,
'9999999'),:APP_USER,:P164_FIRST_NAME,:P164_LAST_NAME,:P164_EMAIL,:P164_SKYPE_ID,:P164_COUNTRY,:P164_DATE_OF_BIRTH)
Error report - Unknown Command
PKG_Generate_GRNo.GenerateGR(TO_NUMBER(:P164_APP_ID,
'9999999'),:APP_USER,:P164_FIRST_NAME,:P164_LAST_NAME,:P164_EMAIL,
:P164_SKYPE_ID,:P164_COUNTRY,:P164_DATE_OF_BIRTH);
Session state protection violation is definitely an Apex error, relating to your page settings. It seems your package is trying to change the state of a read-only page. See this other question.
The item identifier in the error message P164_COURSECOUNT has the same prefix as the parameters you pass to the package (:P164_APP_ID) so presumably they relate to the same page. We know nothing about your application or its architecture, so it's hard to offer concrete advice. Maybe you need to change the page or item settings, maybe you need to change what the package does. Only you can tell the right course of action.
As you didn't post the whole command, a note: you have to enclose it into begin-end block, e.g.
BEGIN
PKG_Generate_GRNo.GenerateGR (TO_NUMBER ( :P164_APP_ID, '9999999'),
:APP_USER,
:P164_FIRST_NAME,
:P164_LAST_NAME,
:P164_EMAIL,
:P164_SKYPE_ID,
:P164_COUNTRY,
:P164_DATE_OF_BIRTH);
END;
/
After I checkout choosing instamojo as my payment option, the following error shows up. I filled in the email field in the billing details and yet, it shows up. How do I fix this?
Notice: Undefined index: email in /home/thecoxiy/public_html/catalog/controller/payment/instamojo.php on line 42
/This is the instamojo.php file
This is the error
I tried commenting the email line (line 42) in which case 'this field may not be blank' still shows up except without the error message
I think the quick fix to this would be to push the email to session data and fetching it from there instead of order_info array, before you send it to instamojo.. I hope that should help.
I am working with the paypal express checkout API and am having issues.
I have a request like so:
METHOD=SetExpressCheckout
...
&L_PAYMENTREQUEST_0_NAME0=Individual%20Gross%20&%20Net
&L_PAYMENTREQUEST_0_AMT0=65.00
&L_PAYMENTREQUEST_0_QTY0=1
&PAYMENTREQUEST_0_AMT=70.26
&PAYMENTREQUEST_0_TAXAMT=5.26
&PAYMENTREQUEST_0_ITEMAMT=65.00
&PAYMENTREQUEST_0_PAYMENTACTION=Sale
&PAYMENTREQUEST_0_CURRENCYCODE=USD
I have reviewed this many times and see no error in the math, yet this is what paypal sends me.
TIMESTAMP : 2017-03-22T01:41:05Z
CORRELATION ID : e22e8009c7018
ACK : Failure
VERSION : 88.0
BUILD : 31129382
L_SEVERITYCODE0 : Error
Error Code : 10413
Transaction refused because of an invalid argument. See additional error messages for details.
The totals of the cart item amounts do not match order amounts.
I found that PayPal responded this way because I did not include L_PAYMENTREQUEST_0_NUMBER0 . After including that field, it was accepted. I must say that the error message sent to me lead to me to the wrong issue
My fix engine keeps rejecting messages and I was hoping someone could help me figure out why... I'm receiving the following sample message:
8=FIXT.1.1 9=518 35=AE 34=4 1128=8 49=XXXXXXX 56=YYYYYYY 52=20130322-17:58:37 552=1 54=1 37=Z00097H4ON 11=NOREF 826=0 78=1 79=NOT SPECIFIED 80=100000.000000 5967=129776.520000 453=5 448=BCART6 452=3 447=D 448=BARX 452=1 447=D 448=BARX 452=16 447=D 448=bcart6 452=11 447=D 448=ABCDEFGHI 452=12 447=D 571=6611540 150=F 17=Z00097H4ON 32=100000.000000 38=100000.000000 15=EUR 1056=129776.520000 31=1.2977652 194=1.298120 195=-3.5480 64=20130409 63=W2 60=20130322-17:26:50 75=20130322 1057=Y 460=4 167=FOR 65=OR 55=EUR/USD 10=121
8=FIXT.1.1 9=124 35=3 34=4 49=XXXXXXX 52=20130322-17:58:37.917 56=YYYYYYY 45=4 58=Tag appears more than once 371=448 372=AE 373=13 10=216
But as you can see it's being rejected by the quickfix engine. I am using the 5.0sp1 data dictionary and have configured it in my config file:
[DEFAULT]
ConnectionType=initiator
HeartBtInt=30
ReconnectInterval=10
SocketReuseAddress=Y
FileStorePath=D:\XXX\Interface\ReutersStore
FileLogPath=D:\XXX\Interface\ReutersLog
[SESSION]
BeginString = FIXT.1.1
SenderCompID = XXXXX
TargetCompID= YYYYY
DefaultApplVerId = FIX.5.0
UseDataDictionary=Y
AppDataDictionary=FIX50SP1.xml
StartDay=sunday
StartTime=20:55:00
EndTime=06:05:00
EndDay=saturday
SocketConnectHost= A.B.C.D
SocketConnectPort= 123
Does anyone have any idea why the Engine would be rejecting this message? I know that quickfix is normally able to handle messages with repeating groups, is it a config thing? Any help would be greatly appreciated!
Your message seems to be in order. Try putting this in your config file.
ValidateFieldsOutOfOrder=N
Quickfix by default puts that as Y and the underlying structure storing the tab and field values is unable to see the count before. 453 > 448.
As a sidenote always check these fields. They should point you to the source of the problem.
58=Tag appears more than once
371=448
Maybe it's a shot in the dark, but I had a similar a problem when using a 5.0sp2 dictionary.
I resolved using an updated version of the quickfix library compiled from the library SVN repository. If I remember correctly this was the bug.
It seems that the quickfix library has not been updated since a long time, and for newer version of fix I suggest you to use the "trunk" of the repo.
I had the same problem and i resolved it by tweaking my DataDictionary like the following in message AE TradeCaptureReport