Failing to save an attachment

In a Xamarion.iOS app I try to save an attachment like this

var revision = document.CurrentRevision.CreateRevision();
revision.SetAttachment(question.HeroImage, question.ImageMediaType, question.ImageData);
var savedRev = revision.Save();

The input arguments are 4a/4/4q.png, image/png and byte array contains 46801 bytes. Saving throws the attached exception.

Any help would be appreciated,
Martin

Database: Error serializing {questionId4a.4 #} to JSON
System.ArgumentNullException: Value cannot be null.

Parameter name: method

at Newtonsoft.Json.Utilities.ValidationUtils.ArgumentNotNull (System.Object value, System.String parameterName) [0x00003] in :0
at Newtonsoft.Json.Utilities.ExpressionReflectionDelegateFactory.CreateParametrizedConstructor (System.Reflection.MethodBase method) [0x00000] in :0
at Newtonsoft.Json.Serialization.JsonDictionaryContract.CreateWrapper (System.Object dictionary) [0x0005a] in :0
at Newtonsoft.Json.Serialization.JsonSerializerInternalWriter.SerializeValue (Newtonsoft.Json.JsonWriter writer, System.Object value, Newtonsoft.Json.Serialization.JsonContract valueContract, Newtonsoft.Json.Serialization.JsonProperty member, Newtonsoft.Json.Serialization.JsonContainerContract containerContract, Newtonsoft.Json.Serialization.JsonProperty containerProperty) [0x00129] in :0 at Newtonsoft.Json.Serialization.JsonSerializerInternalWriter.SerializeDictionary (Newtonsoft.Json.JsonWriter writer, IDictionary values, Newtonsoft.Json.Serialization.JsonDictionaryContract contract, Newtonsoft.Json.Serialization.JsonProperty member, Newtonsoft.Json.Serialization.JsonContainerContract collectionContract, Newtonsoft.Json.Serialization.JsonProperty containerProperty) [0x0014f] in :0
Database: System.ArgumentNullException: Value cannot be null.
Parameter name: source
at System.Linq.Enumerable.ToList[TSource] (IEnumerable`1 source) [0x00006] in /Users/builder/data/lanes/2689/962a0506/source/maccore/_build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/src/mono/external/referencesource/System.Core/System/Linq/Enumerable.cs:834
at Couchbase.Lite.Database+c__AnonStorey5.<>m__0 () [0x002fc] in /Users/zgramana/Source/couchbase-lite-net/src/Couchbase.Lite.Shared/Database.cs:3136
at Couchbase.Lite.Database+c__AnonStorey0.<>m__0 () [0x0000e] in /Users/zgramana/Source/couchbase-lite-net/src/Couchbase.Lite.Shared/Database.cs:686
System.ArgumentNullException: Value cannot be null.

Parameter name: source

at System.Linq.Enumerable.ToList[TSource] (IEnumerable`1 source) [0x00006] in /Users/builder/data/lanes/2689/962a0506/source/maccore/_build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/src/mono/external/referencesource/System.Core/System/Linq/Enumerable.cs:834

at Couchbase.Lite.Database+c__AnonStorey5.<>m__0 () [0x002fc] in /Users/zgramana/Source/couchbase-lite-net/src/Couchbase.Lite.Shared/Database.cs:3136
at Couchbase.Lite.Database+c__AnonStorey0.<>m__0 () [0x0000e] in /Users/zgramana/Source/couchbase-lite-net/src/Couchbase.Lite.Shared/Database.cs:686

That error message has not existed in that location since 1.1.0. Does this problem still occur with the latest version? The message you mentioned with the line numbers you gave indicate that you have a revision whose properties are null or contain an invalid property name (note that property names starting with _ are reserved for the library)

Upgrading to the latest version gave me a different exception thrown higher up in the call stack. This mean that I could examine the revision object in the debugger. The exception I reported in the original post was thrown after the revision had been garbage collected, which did not help.

Turned that I had given an attachment the same name as an existing field.

I am not sure if this is the intended behaviour or not. If it is, I think it would be worth updating your documentation to mention this restriction.

I have now come across another issue, which might be a genuine bug in Couchbase. Calling revision.setAttachment with a byte array as the third argument raises an exception if an attachment with the same key already exists.

Let me know if you need any more info to reproduce this issue or prefer me to report it on GitHub.

Martin

PS, At the moment there is no requirements to update the downloaded images so as a work-around I check if an attachment exists and avoids to overwrite them.

I tried various permutations of this and was not able to reproduce it. Could you provide the stack trace? That would help me get an idea of where things might go wrong.