XMLRPC response "TypeError: cannot marshal None unless allow_none is enabled" despite using "allow_none=True"

[esciara]

Impacted versions:
9.0c and 9.0e

Steps to reproduce:
Here is the code I used on a locally installed and running Odoo 9: (even more details on tinyerp/erppeek#87)

server = 'http://localhost:8069'
username = 'admin'  # The Odoo user
pwd = 'admin'  # The password of the Odoo user
dbname = 'ErpPeekDemoDatabase'  # The Odoo database

#
# Use erppeek to create the database, install the modules (it is easier :) )
#
import erppeek

client = erppeek.Client(server)
try:
    client.login(user=username, password=pwd, database=dbname)
except erppeek.Error as erppeek_err:
    # Database probably does not exist. Create it
    client.create_database(passwd=pwd, database=dbname)

client.install('sale')
client.install('website_sale_delivery')

#
# Use xmlrpclib to create records
#
import xmlrpclib

# OpenERP Common login Service proxy object
rpcpath = server + '/xmlrpc/'
sock_common = xmlrpclib.ServerProxy(rpcpath + 'common', allow_none=True)
uid = sock_common.login(dbname, username, pwd)

sock = xmlrpclib.ServerProxy(rpcpath + 'object', allow_none=True)

# Calling the remote ORM create method to create the records
delivery_carrier_id = sock.execute(dbname, uid, pwd, 'delivery.carrier', 'create',
                                   {'name': 'Test delivery carrier',
                                    'delivery_type': 'fixed',
                                    'fixed_price': 10,
                                    'product_type': 'service',
                                    'partner_id': 1})
sale_order_id = sock.execute(dbname, uid, pwd, 'sale.order', 'create', {'carrier_id': delivery_carrier_id,
                                                                        'partner_id': 1})

# Calling the delivery_set method, which returns nothing and 
# makes xmlrpc throw a `TypeError: cannot marshal None unless allow_none is enabled` error
result = sock.execute(dbname, uid, pwd, 'sale.order', 'delivery_set', sale_order_id)

Current behavior:
Throws xmlrpclib.Fault: <Fault cannot marshal None unless allow_none is enabled: 'Traceback [..]'> when calling delivery_set on sale.order.

Expected behavior:
No exception thrown (or else?)

Video/Screenshot link (optional):
N/A

Other related links found:
#1055
#1284

[dreispt]

That's a known limitation of XMLRPC.
The solution is to make sure that the method returns a value; at least return True.
Confirm that and make a PR adding the needed return value,

[esciara]

Won't be able to do that soon, but will eventually.

[xmo-odoo]

As @dreispt notes that's a limitation of "standard" XML-RPC, for the current RPC API Odoo doesn't enable the nil extension, and it won't be enabled as that would be a backwards-incompatible change (existing client may not have enabled this extension and would thus break). As a result, model methods callable over RPC must return a value of some sort, usually True or False if there's nothing better to return.

Of note, since a new RPC API will eventually have to be set up to finalise the deprecation and removal of the V7 API, we should be able to allow_none for the "new" RPC.

[esciara]

@xmo-odoo thanks for the details. You closed the ticket though and I have not created a PR yet... Shall I still create one for this?

[xmo-odoo]

@esciara

You closed the ticket though and I have not created a PR yet... Shall I still create one for this?

Nah I'm going to fix it right now, it was actually already fixed in dc043cf back in January but @rim-odoo only fixed it in saas-10 onwards. I'll backport the change to 9.0.

[esciara]

Hi,

Changed the code on my instance exactly the same way you did, restarted Odoo, still the same issue... Am I missing something?

[HarshitTBrainvire]

Facing issue for "TypeError: cannot marshal <class '_thread.lock'> objects" python version 3.6 and odoo12

[xmo-odoo]

@HarshitTBrainvire you'd have to explain what call you're making for that to happen, because returning a lock over RPC is never going to work, and though I'm a bit doubtful this would occur in standard code it's a distinct possibility as the json-rpc serialization code tends to hide these issues under the cover (by stringifying everything).