roomorama / concierge Goto Github PK

When a successful reservation is cancelled, concierge do not track the "cancelled" state, but list the reservation row normally. For example, a ciirus test reservation was cancelled, then a new booking was created on the same date. We see the first booking (12212627) not indicated as cancelled:

Description

Sometimes, we try to get rates for properties that are deemed to be "deleted from the system". Here's the error message:

(soap:Server) Server was unable to process request. ---> GetPropertyRates: Validation Error 2 - Property has been deleted from the system.

However, sometimes the error message is just "Validation Error 2", but there is no "property deleted" message:

(soap:Server) Server was unable to process request. ---> GetPropertyRates: Validation Error 2

Possible solutions

We need to ask Ciirus why we get IDs for properties that are deleted. If that's expected behaviour, we should probably just skip such properties.

We also need to ask whether the "Validation Error 2" without the "Property has been deleted from the system" message has the same meaning.

Occurrences

• includes the "property deleted" message - #307112, #307101 and #307100
• No "properties deleted" message - #307105, #307098 and #307097

As I understand from Supplier Credentials and Environment Variables sections of project's README we don't need to add credentials env vars to the apps/api/config/environment_variables.yml

But @keang added it both for wts and ciirus suppliers.

@rmascarenhas could you please clarify this situation?

Description

During the sync process, a get_property_permissions SOAP operation is performed. However, that call might return an error with the following message:

Error (1012-CS) This property has been deleted. Please contact the inventory supplier.

Possible solutions

We likely need to contact Ciirus about it. Perhaps it's just a variation of #275, and we need to skip the property. But we need to ask to be sure.

Occurrences

#308743

Description

When fetching information for Ciirus properties, sometimes it returns an error informing that the property contains "demo images". Error message

(soap:Server) Server was unable to process request. ---> GetImageList: This property contains demo images.

Possible solution

We need to ask them what that message even means. Just from reading it it's hard to know what's going on.

Occurrences

#306067 (the property is not presented anymore)
#342388

Just want to discuss one thing.

During sync process possible situations when property just isn't suitable for Roomorama (on request only, don't have active rates to calc nightly_rate or something else) in this case we just skip it and get next property.
But at the end of sync process we don't know how many properties we skipped. May be I made little mistake in my code and a lot of properties were silently skipped.

So guys (@rmascarenhas @keang @sharipov-ru @Traf333), what do you think about adding skipped_counter to SyncProcess?

Description

Properties have a minimum_stay field which Concierge supplier mappers are expected to fill. However, for some Kigo properties, the minimum stay we have on our database does not match their error description when quoting prices.

Property with Kigo ID 225298 is registered to have a minimum stay of 30 days on our database. However, during a quote price operation, this was the error message:

{
  "API_VERSION": 1,
  "API_REVISION": 3,
  "API_METHOD": "computePricing",
  "API_CALL_ID": "d40a36fb-e723-4abf-9f39-88cce59501dd",
  "API_RESULT_CODE": "E_CONFLICT",
  "API_RESULT_TEXT": "The property pricing information is unavailable due to a constraint. This Property has a minimum stay of 25 nights.Unfortunately, this unit is not available for your selected period. Please try another unit.",
  "API_REPLY": null
}

Possible solutions

We have to investigate why we have incorrect mapping our database. It could be a bug on our code or in their data, or in our understanding of their data. Ideally, it's of our best interest to have such information correctly set so that we avoid making API calls to Kigo when Roomorama knows beforehand that the minimum stay is not compatible.

Occurrences

Cases when the minimum stay is correctly mapped: #343068, #343070

Cases when the minimum stay is incorrect (there could be more): #343067

Description

When publishing properties for the first time, a number of parameters are sent with to aid the process of assigning a destination for a new property: address, city, country, coordinates, postcode, among others.

However, oftentimes an error is returned due to the fact that no destination could be assigned to the property.

Possible solution

Probably will have to rely on a error-by-error approach, and see if we can find any pattern among the failures which would help matching destinations to properties

Occurrences

Ciirus

Below are just samples, more occurrences of each have happened.

• No destination found: #306125, #306124, #306123, #306122, #306078
• Postal code missing or invalid: #306079

Poplidays

• https://concierge-web.roomorama.com/errors/358937
• https://concierge-web.roomorama.com/errors/358907

Description

Sometimes, when requesting for rates for a Ciirus property, their webservice returns that "no rate rows are available". We learned from them that that's a possible scenario, and happens when the property manager has not specified any rates for the Ciirus/Roomorama connection.

Possible solution

We should just skip such properties, and let them get published whenever rates are set. I was under the impression that #260 was supposed to be a fix for this, but apparently the error is still happening (see the occurrences section, where a link for an error on version 0.7.3 happens.)

I think this still needs fixing. @keang please correct me if I misunderstood something.

Occurrences

#307093

Description

When trying to publish properties to Roomorama, the coordinates sent are "0"for both latitude and longitude. As a result, Roomorama fails, usually with a "invalid postal_code" error (due to the fact that it failed to geocode the property.)

Possible solutions

We need to investigate our coordinates mapper to check if it's problems with data coming from Ciirus or from our mapping.

@adler, perhaps we should have a more descriptive error message and fail early if the coordinates are not valid (right now it's "invalid postal code", and it's hard to know what caused it.) What do you think?

Occurrences

#307311, #307310, #307309

I'm feeling that I don't fully understand context.disable! purpose.

Here is good @rmascarenhas's description from #103

disable! allows the caller to suppress context tracking in certain scenarios. The most common of which being synchronisations which perform bulk API calls with large return response bodies, such that keeping that in the context (in memory during the transaction and persisted in the database for later analysis) is sort of pointless.

But what is bulk call? For some hosts Ciirus returns >50 properties and then performs several remote calls but we don't disable context there.

Poplidays returns thousands properties but @keang suggests don't disable context there.

As I understand when context is disabled context.augment has no sense. But in AtLeisure we disable context only for API response parsing where, as I see, we don't do context.augment at all.

May be I'm missing something but I can't find useful context disable examples in our code.

Please comment the issue and give me a ray of light ☀️

thank you

Current Calendar#parse_entries method:

    def parse_entries
      return empty_response if entries.empty?

      sorted_entries = entries.select(&:valid?).sort_by(&:date)
      start_date     = sorted_entries.first.date
      end_date       = sorted_entries.last.date

      rates          = Rates.new([], [], [])
      parsed_entries = ParsedEntries.new(start_date, "", "", "", [], rates, [])

      # index all entries by date, to make the lookup for a given date faster.
      # Index once, and then all lookups can be performed in constant time,
      # as opposed to scanning the list of entries on every iteration.
      #
      # Implementation of what Rails provide as the +index_by+ method.
      index = {}.tap do |i|
        sorted_entries.each do |entry|
          i[entry.date] = entry
        end
      end

      (start_date..end_date).each do |date|
        entry = index[date] || default_entry(date)
        ...
      end

As well as calendar.to_h is used in case when it is invalid this method should be resistant to invalid calendar. And, as I understand, that is why we build index by all the entries (valid and invalid). But if some invalid entry affect determine of start_date or end_date we will not see this entry in the result of to_h function.

If this problem is important I suggest to discuss possible solutions. I couldn't find elegant one. I tried to remove .select(&:valid?) but if some entry doesn't contain date we have an error.

May be the best solution create separate to_h method for invalid calendar case.

@rmascarenhas please let me know what do you think.

Description

Sometimes, when requesting for rates for a Ciirus property, their webservice returns

(soap:Server) Server was unable to process request. ---> GetPropertyRates: Error - No Rate Assigned by user. Please contact the user and request they populate this data.

There was similar issue #276 but with other message.

Possible solution

We should just skip such properties, and let them get published whenever rates are set.

Occurrences

#356541

https://rollbar.com/Roomorama/Concierge/items/67/

Reason

Unexpected response format

How to fix

Investigate response
Update code

Description

Currently we have the column :code on ExternalError which breaks down as follows on production:
http_status_422, soap_fault, missing_data

This is useful up to a point, but much effort is still needed to read the actual context to know "Oh it's that error"

Once we get that level of recognisability the grouping and tracking, checking for resolved issues, would be much easier. When that is achieved we can try tools like Rollbar which has useful features like counts, mark as resolved, etc..

Solution

Be more generous with the length of ExternalError#code:

2.3.1 :001 > e = Result.error("(soap:Server) Server was unable to process request. ---> GetPropertyRates: Error - No Rate Assigned by user. Please contact the user and request they populate this data.")
 => #<Result:0x007fd92ed3b378 @result=nil, @error=#<struct Result::Error code="(soap:Server) Server was unable to process request. ---> GetPropertyRates: Error - No Rate Assigned by user. Please contact the user and request they populate this data.", data=nil>>

Or even add a new "Title" column?

This would mean that we have to go to each supplier clients and forward the useful information as that result's code (or title)

• Ciirus implementation knows how to parse the soap_fault from ciirus,
• Similarly for all suppliers,
• Roomorama publish client knows what to expect from failing response (like "Missing postal code" is always in the errors field)

Description

When mapping data from WayToStay's API to Roomorama's format, sometimes no images are set for a property. In such cases, the publish request is not even set to Roomorama, and the process is aborted.

Possible solutions

Apparently #263 was supposed to fix this issue (or a similar one), but there are still occurrences in version 0.7.3 (see Occurrences section.)

@keang correct me if I'm misinterpreting something.

Occurrences

#307054, #307053, #307051

https://www.roomorama.com/short-term-rentals/new-york/morningside-heights/house/456165
Ciirus identifier: 87166
Host username: Jeffandrews56

During metadata sync concierge sent next JSON
PUT https://api.staging.roomorama.com/v1.0/host/apply

{
  "identifier": "627580",
  "pets_allowed": false,
  "security_deposit_amount": 200.0,
  "security_deposit_currency_code": "EUR",
  "default_to_available": false
}    

and got next error

{
  "status": "error",
  "errors": {
    "deposit": [
      "Security deposit is not a number"
    ]
  }
}   

200.0 is a number, isn't it?

@rmascarenhas could you please look at this?

Description

For some properties, when fetching data for a property, their webservice indicates that no images were set for the property. Error message:

(soap:Server) Server was unable to process request. ---> GetImageList: Error - No Images exist for this property at this time. Please contact the user and request they populate this data.

Possible solutions

At the very least, we should ask how this is possible on Ciirus so we understand how it works. It's possible that something similar to the situation we have with rates is happening here: the property manager has not set any images for the Ciirus/Roomorama connection. But better to make sure and ask how w ecan "request they populate this data".

Occurrences

#306071, #306070

Description

When publishing properties to Roomorama, all address information is used to determine the property's location. However, sometimes SAW's data returns us invalid postcodes (such as ".")

Possible solutions

When contacted about this issue, they guaranteed we would not face it on production. Turns out the same happens. We need to communicate with them and hopefully they will have the data fixed.

Occurrences

#307469, #307468

Description

When we sync metadata for some properties we get http_status_422 error:

{
  "status": "error",
  "errors": {
    "images_0_identifier_delete": "identifier 16fae863a1bbe4c46ad83e9bfa4e3ce6 not found",
    "images_1_identifier_delete": "identifier 2cc61f88529cdd30d6352a9971369658 not found"
  }
}  

I don't know what is the problem. @keang could you please add description and possible solutions about the issue?

Possible solutions

Occurrences

#354963

Description

Some quote requests are arriving for Concierge where the number of guests is larger than the maximum number of guests, a known configuration

Possible solutions

We should not quote stays when the requested number of guests is larger than that allowed. This is a fix on Roomorama, but I decided to address it here to group supplier improvements.

Occurrences

#307492, #307491

Description

Sometimes after some bug fixes, we want to manually trigger a sync, to monitor and reduce the scope of external_errors to look through

It would be nice to be able to click "Resync" on this page:

Description

Kigo sync operation hits the rate limit:

{
  "statusCode": 429,
  "message": "Rate limit is exceeded. Try again in 1 seconds."
}    

Possible solutions

Sync worker throttle the request

Occurrences

here and here

On friday (2016-08-05) tried to test metadata sync with Roomorama staging and got 500 error. The error is still there for all properties I try to sync. Here is an example of full payload:

POST https://api.staging.roomorama.com/v1.0/host/publish
User-Agent: Roomorama/Concierge 0.5.4
Authorization: Bearer FnfXa1WiuiFBarRcPNpXmKxNGaHyxEKMjdq5z650fNA
Content-Type: application/json

Request body:

{
  "identifier": "8943134097",
  "type": "apartment",
  "subtype": "apartment",
  "title": "Rental Apartment Medulin - Medulin, studio flat, 4 persons",
  "description": "These holiday apartments are located near the town centre of Medulin. The apartments are connected to each other by an internal staircase which is shared by the guests. The interiors are meticulously furnished with many colours and traditional details. Each apartment has a covered terrace, where the guests can relax and have a great time. There are many tourist attractions in and around Medulin, apart from various beautiful beaches. Available on site with supplement: Bedlinen incl. towel - 0.0 EUR per person; Final cleaning - 0.0 EUR per stay;\n\n",
  "address": "15 Katikulic",
  "postal_code": "52203",
  "city": "Medulin",
  "country_code": "HR",
  "lat": 44.82345268342922,
  "lng": 13.93763780593872,
  "number_of_bedrooms": 1,
  "number_of_bathrooms": 1,
  "surface": 44,
  "surface_unit": "metric",
  "amenities": "kitchen,tv,parking,outdoor_space",
  "max_guests": 4,
  "minimum_stay": 3,
  "multi_unit": false,
  "smoking_allowed": true,
  "pets_allowed": false,
  "currency": "EUR",
  "nightly_rate": 39.46,
  "weekly_rate": 276.22,
  "monthly_rate": 1183.8,
  "security_deposit_amount": 300.0,
  "security_deposit_currency_code": "EUR",
  "default_to_available": false,
  "cancellation_policy": "super_elite",
  "instant_booking": true,
  "images": [
    {
      "identifier": "eaa51b6c2969d46857cf250fa237341f",
      "url": "http://cdn-prod.poplidays.com/v2/pictures/8943134248-620x465.jpg"
    },
    ...
  ]
}    

Clock Icon 23:35:56 (+0200)
Network Response

As a response of the previous call, the server responded with status 500 and the following response headers:
Content-Type: text/html; charset=utf-8
Date: Sun, 07 Aug 2016 21:35:56 GMT
Server: nginx
Status: 500 Internal Server Error
X-Request-Id: 8cf33be1-768c-43f4-80cb-6d47058d458d
X-Runtime: 0.795550
Content-Length: 0
Connection: keep-alive

@rmascarenhas I wrote about this bug to you in slack.

During calendar sync test with Roomorama staging I found strange behavior for some of properties.
Here is my host page https://staging.roomorama.com/users/konstantin_ciirus_host there are 3 properties, for all of them I made calendar sync (without errors and with good availabilities periods) but only the last one correctly displays it in UI calendar.

Here is payload I sent for https://staging.roomorama.com/short-term-rentals/kissimmee/house/442983?origin=user_profile

{
  "identifier": "46864",
  "start_date": "2016-08-03",
  "availabilities": "000111111111110000000000000001111111111111111111111111111111111111000000000000000000000111111111111111111111111111111111111111111111111111111111111111111",
  "nightly_prices": [
    122.86, 122.86, 122.86, 122.86, 122.86, 122.86, 122.86, 122.86, 122.86, 122.86, 122.86, 122.86, 122.86, 122.86, 122.86, 122.86, 122.86, 122.86, 122.86, 122.86, 122.86, 122.86, 122.86, 122.86, 122.86, 122.86, 122.86, 122.86, 122.86, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 114.29, 92.14, 92.14, 92.14, 92.14, 92.14, 92.14, 92.14, 92.14, 92.14, 92.14, 92.14, 92.14, 92.14, 92.14, 92.14, 92.14, 118.57, 118.57, 118.57, 118.57, 118.57, 118.57, 118.57, 118.57, 118.57, 118.57, 118.57, 118.57, 118.57, 118.57, 118.57, 118.57, 118.57,
  "minimum_stays": [
    4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4
}

but UI calendar is empty.

@rmascarenhas could you please look at my problem?

For the payload below I got next error:

{
  "identifier": "46849",
  "type": "house",
  "subtype": "villa",
  "title": "***Starbird Court",
  "description": "This fabulous five bedroom home is situated on Sandy Ridge. Ideally located for all the main Orlando attractions and close to the championship golf courses of Reunion and Champions Gate.<br><br>Furnished to a very high standard with 2 Master En-suites, this home is ideal for a large family or two. <br><br>This quiet neighborhood has a peaceful and tranquil feel ideal for anyone who needs to get away, and have some quite time.  <br>The pool and spa overlook the pond, the ideal setting for that evening cocktail after a long day at the parks.<br>The golf coast is only 55 minutes away. Disney parks are 15 minutes away.<br>",
  "address": "118 Starbird Court",
  "postal_code": "33896",
  "city": "Davenport",
  "country_code": "US",
  "lat": "28.2549725",
  "lng": "-81.5651270",
  "number_of_bedrooms": 5,
  "number_of_bathrooms": 4.0,
  "number_of_double_beds": 3,
  "number_of_single_beds": 4,
  "number_of_sofa_beds": 0,
  "amenities": "wifi,internet,tv,airconditioning,pool",
  "max_guests": 10,
  "minimum_stay": 5,
  "multi_unit": false,
  "pets_allowed": false,
  "currency": "USD",
  "nightly_rate": 151.0,
  "weekly_rate": 1057.0,
  "monthly_rate": 4530.0,
  "default_to_available": false,
  "cancellation_policy": "moderate",
  "instant_booking": true,
  "images": [...]
}  

Error

{
  "status": "error",
  "errors": {
    "destination_id": [
      "Could not find a suitable destination to list this property under, please contact Roomorama at [email protected] stating the address you were trying to list"
    ]
  }
} 

I would like to propose having another operation by concierge's worker: Roomorama::Client::Operations::UpdateCalendar.

So that we'll have:

1. Background process that pushes data to roomorama.com

CONCIERGE --req--> SUPPLIER --res--> CONCIERGE --req--> ROOMORAMA.COM

• property (create, diff/update, disable)
• availability (true/false)
• calendar (nightly, weekly rates) <------ new

2. Webhooks where data is pulled by roomorama.com

RMRM --req-->CONCIERGE --req-->SUPPLIER --res--> CONCIERGE --res--> RMRM

• quote
• book
• cancel
• calendar (one half is done by https://github.com/roomorama/roomorama/pull/3558)

This is because for suppliers that implements diff/changes like kigo/waytostay, it makes sense that the rates are pushed to roomorama.com instead, since that is returned in the /changes calls. In contrast for calendar pulling, we have to walk through all imported properties, resulting in many redundant requests.

Description

When applying a set of changes for a property, the Roomorama API returned the error message above.

Possible solutions

Investigate the occurrence and fix it on Roomorama's API. However, the occurrence itself is a bit suspicious, trying to set many fields to nil.

Occurrences

#306575

Current concierge sync process:

1. create supplier "Ciirus" on roomorama
2. create host on roomorama with webhooks at /create-host
3. take the returned access_token and create host on concierge with Flow::HostCreation
4. each host will have sync jobs (metadata & availabilities) that run as specified in suppliers.yml

We want to automate 2 and 3.

Maybe we can:

1. create supplier "Ciirus" on roomrama

2. Start a supplier worker, which checks if there're any new host that just started sharing properties with bridge. If found:

   a. call roomorama's create-host api
   b. create concierge host with returned access_token from roomrama, and host_fee_percentage from ciirus

3. each host will have sync jobs (metadata & availabilities) that run as specified in suppliers.yml

Here is the list of country fields getting from the Ciirus API (production data):

'USA', 'Cyprus', 'Turkey', 'CY', 'US', 'Famagusta', 'USA3', 'usa', 'Usa', 'United States', 'Cyrus', 'EUA', 'AW', 'united states', 'Polk', 'U.S.A.', 'USA ', 'Mexico', 'UAE', 'USA ', 'Aruba', 'Paralimni', 'usa ', 'UNITED STATES', '34746', 'Larnaca', 'UAe', 'U.S.A', 'FL', 'United States of America', 'Osceola', 'UK', 'United States of America', 'UNITE STATES', '34741'

Looks like this is typed by usual users and doesn't have predefined format (ISO alpha2, etc).
I've implement country code converter, but with the amount of rubbish it may return wrong result.

What is the best way to handle this?

Description

When quoting prices for a unit in SAW, the request performed requests for the price of the property in the requested dates, and the response is supposed to include the rates for all units of that property in that check-in/check-out combination. However, sometimes the response does not include the rates for the requested unit itself, and we are unable to return the rate.

Possible solution

We need to contact them to know what to do in such scenarios. Perhaps this just means the unit is unavailable, or we might not be using the API correctly, or it could be an issue on their API.

Occurrences

#307065, #307087, #307088

Description

When fetching rates for properties from Ciirus' webservice, it's possible to get a response indicating that "monthly rates are not provided via API". Error message

(soap:Server) Server was unable to process request. ---> GetPropertyRates: Monthly Rates Not Supported via API. Monthly Rates Set By User. Please contact the Unit Supplier to configure a supported rate type for your channel.

Possible solutions

We should either skip these properties or contact Ciirus about the meaning of the message above. @kkolotyuk do you have any clue what the message above means?

Occurrences

#306058, #307337, #307336

Ciirus host has a lot of freedom, and sometimes they publish properties with invalid details.
This is a common issue the caused a number of errors:

• #260 (patched, should revert if needed), #276 Rates is empty or is 0.0
• #280 Coordinates at (0, 0)
• #279 Monthly rates not provided
• #278 Demo images
• #277 No images set
• #274 Empty description from supplier

Currently these properties are not published, so the issue is not critical. However they are flooding the external errors, and we might want to handle these expected exceptions and handle them better.

Ciirus suggest we contact the host to ask for complete property details:

The most ideal method is that if the user has not defined rates, the unit is disabled, the user is notified, and once they have corrected the issue, they would notify you to re-enable it. I am not sure if this is feasible from a user experience perspective, so your suggestion sounds right, but if a user had a good number of units without rates, they will not be transacting. This would mean system utilization from both of our companies without any prospect of payment for this service. One way or the other, I think the crucial difference to your suggestion which is very necessary would be to notify the PM/Manager so they know why their units are not booking. They may not check very closely in all cases how many units have been disabled.

Solution

Do not create external_errors, but record these occurrences somewhere else, so that we can contact the hosts later if it makes business sense.
As #260 patch is, the error is just silenced, and we may lose data on a potential area to increase the inventory.

Hi Guys,

(specially @rmascarenhas, @Traf333, @keang, @adlersantos)

We have to make sure that all integration works on test environments. For instance, if someone is using sandbox, he should be able to make bookings safely and successfully. It is annoying having to know by heart what are the partners who work and who doesn't work in staging.

So my suggestion is to make sure we implement it in each integration even if the partner doesn't have it.

Another topic in the same subject is: should we have test properties in production? I am in favour of having it, and adding a rooms.test = true/false column in db.

What you think?

Description

When one of the calendar entries for a property: has no nightly rate; does not indicate availability; or has an unrecognisable date, the calendar synchronisation fails. This seems to have happened when synchronising the calendar for a property.

Possible solutions

The occurrence log is huge due to the nature of the requests, so it's probably going to be hard to pinpoint the issue, but probably still doable.

Occurrences

#307059

Description

Looking at the occurrence context, only getPropertyPricing was requested. Description field is empty and Roomorama rejects the publish attempt.
Could be a bad context managing too.

Occurrence

https://concierge-web.roomorama.com/errors/358905

While SAW supplier integration I noticed that their API allows only booking requests with provided currency_code. In case if currency_code is different from what they have for particular property they return an error saying

Booking in different currency are not allowed to this affiliate. Please contact Serviced Apartments Worldwide for more detail on it.

In the previous platform currency_code was a part of webhook parameters: https://www.roomorama.com/api/instant#instant-webhooks

In concierge there is a list of white-listed attributes defined in middlewares/roomorama_webhooks:

          params = {
            property_id: payload.get("inquiry.room.property_id"),
            unit_id:     payload.get("inquiry.room.unit_id"),
            check_in:    payload.get("inquiry.check_in"),
            check_out:   payload.get("inquiry.check_out"),
            guests:      payload.get("inquiry.num_guests"),
            subtotal:    payload.get("inquiry.subtotal"),
            customer: {
              first_name: payload.get("inquiry.user.first_name"),
              last_name:  payload.get("inquiry.user.last_name"),
              email:      payload.get("inquiry.user.email"),
              phone:      payload.get("inquiry.user.phone_number")
            }
          }

and this list doesn't support currency_code attribute, so even if I send a test webhook with currency_code, concierge core drops this attribute off.

My suggestion is to discuss whether we can extend parameters list (maybe specifically only for SAW integration?) or find another ways of solving the issue and returning back the crucial attribute.

Description

Some properties are being assigned with both the type and subtype fields as house, which is not valid according to the hierarchy on Roomorama. That prevents the property from being published.

Possible solution

Probably just leaving the subtype blank.

Occurrences

#306059, #306059

Description

When publishing a property, we need to set the initial nightly/weekly/monthly for it. However, for some properties such values are set to 0.0, causing Roomorama to reject the property.

Possible solutions

We need to double check our mapper to make sure it's correctly mapping the data. It could be an issue on our mapper, or on their data, but we need more investigation.

Occurrences

#304683, #303098

We have some stats for each metadata sync on a web ui like:

For now stats looks like:

{"properties_created":0,"properties_updated":0,"properties_deleted":0,"properties_skipped":1}

but can be like this (Ciirus metadata sync worker example):

{
  properties_created: 0,
  properties_updated: 0,
  properties_deleted: 0,
  properties_skipped: [
    {
      reason: "(soap:Server) Server was unable to process request. ---> GetPropertyRates: Error - No Rate Assigned by user. Please contact the user and request they populate this data."
      ids: [a, b, c]
    }, {
      reason: "(soap:Server) Server was unable to process request. ---> GetPropertyRates: Error - No Rate Rows Returned",
      ids: [x, y]
    }
  ]
}

We don't need a fancy ui to accommodate the big hash actually, but just render it there, even if it's hidden by scrolls, because we can copy the json to a text editor or something to analyse.

Description

When publishing a property, one of the required fields is the maximum number of guests the property supports. SAW provides such information using an endpoint to quote prices. However, when the (arbitrarily selected) dates are not available, the information is not returned, even though they confirmed the data does not change over time.

Possible solutions

We need to ask them if there is any way to get the maximum guests information without having to make a call with arbitrary dates, otherwise we will our success in getting that information will depend solely on sheer luck.

Occurrences

#307467, #307466, #307465

After we added error data (the second arg) to soap_client.rb results:

    rescue Savon::SOAPFault => err
      announce_error(err)
      Result.error(:soap_error, err.message)

we can get not user-friendly error messages from webhooks which use SoapClient because here how we generate webhook message:

    error_message = cancellation_result.error.data || { cancellation: GENERIC_ERROR }

For example:

konstantin@laptop:~/projects/concierge$ curl -v -H "Content-Type: application/json" -H "Content-Signature: `./tmp/sign_webhooks.rb ./tmp/cancel.json xxx`" --data-binary @tmp/cancel.json localhost:2300/api/avantio/cancel
* Hostname was NOT found in DNS cache
*   Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 2300 (#0)
> POST /api/avantio/cancel HTTP/1.1
> User-Agent: curl/7.35.0
> Host: localhost:2300
> Accept: */*
> Content-Type: application/json
> Content-Signature: ab442f76e8f872daf9913be7956f6b47763dc7ae
> Content-Length: 95
> 
* upload completely sent off: 95 out of 95 bytes
< HTTP/1.1 422 Unprocessable Entity
< Date: Thu, 15 Sep 2016 10:48:35 GMT
< Connection: close
< Content-Type: application/json; charset=utf-8
< Transfer-Encoding: chunked
< 
* Closing connection 0
{"status":"error","errors":"(soapenv:Client) La reserva no existe"}

So if this errors are for real users it's not so good.
@keang what do you think?

I noticed that booking SAW endpoint is very slow and returns timeouts. SAW API itself is very stable and reliable (I've never seen it in not working state), but exactly booking request is incredibly slow, usually it takes 10-13 seconds to respond.

time http POST http://staging.servicedapartmentsworldwide.net/xml/propertybooking.aspx @~/xml/1_property_booking_input.xml

=>

http POST  @~/xml/1_property_booking_input.xml  0,20s user 0,09s system 2% cpu 12,528 total

As a result, I'm getting connection_timeout error, so I wonder what if we could increase connection timeout time only specifically for SAW client?

=> #<Result:0x007fccaa37a220 @result=nil, @error=#<struct Result::Error code=:connection_timeout, data=nil>>

Description

Some properties are failing to get published because the synchronisation process assigns no description to them. As a result, they are rejected by Roomorama's API.

Possible solution

Apparently, the properties have no plain text description, but do have HTML descriptions (full of random CSS and JS links). We need to review our HTML filtering regex to see if there is any way we can improve it in order to clean the content and read the description.

Occurrences

#306072, #306073

Description

In some cases, the API call to Ciirus to fetch HTML descriptions returns meaningless content. It gets filtered by the regex (as it should) and ultimately fails publishing.

Possible solutions

We need to contact Ciirus and ask why such properties return the meaningless description mentioned. If they can do nothing about it, we'd rather skip such properties instead of recording errors each time.

Occurrences

#306048, #306046

Description

During one sync operation for waytostay, there was a request to apply changes to a property, setting many fields (including required ones) to nil. Apart from that, the request included image identifiers to be deleted which were not recognised by Roomorama.

Possible solutions

This is apparently an occurrence particular to that one property. We need to investigate it separately.

Occurrences

#306611

Description

When quoting prices, sometimes Kigo returns an E_NOSUCH error with the following error message

"API_RESULT_TEXT": "The property was not found, or is unavailable (i.e. was deactivated)."

Apparently, the error is the same even when attempted with multiple dates.

Possible solution

We need to ask Kigo if this really means the property is deactivated from their system and if there is no other way of knowing this information apart from checking prices. Otherwise, we will need to quote for fake prices when synchronising Kigo to determine whether or not the property is live, incurring a huge increase in the number of required calls to run the sync, which could have a very negative impact in our API usage quota.

Occurrences

#387679, #387682, #387681

Description

Ciirus has some property types that we currently skip from publishing. Namely: Office, Barn, Resort, Unspecified and Hotel.

Possible solution

Unspecified is ignored as unknown type, Hotel - because Roomorama doesn't import hotels. The others need to be analysed to check whether or not they make sense for us. We need to check some property examples to determine.

Occurrences

#306057

Notes

Related pull request: #266

If we classify them as others, we need a meaningful subtype.

Description

See title

Occurrence

https://concierge-web.roomorama.com/errors/358893
https://concierge-web.roomorama.com/errors/358904